A vital concept is that the output of one build process can serve as part of the input to another. The export directory is organised as a physical tree that can be used to help define another virtual tree, such that the exported libraries are available as inputs for another MSVC solution. It follows that paths down from the export directory can be regarded as logical paths.
When a .xcws file is used to generate MSVC .vcproj and .sln files, the result depends on whether original or exported versions of projects are found within the input virtual tree. The virtual tree is not defined by the .xcws file, so the same .xcws file can generate quite different development environments to suit the needs of the individual developer.
When a project is exported, a .xcpj file is written to the export directory with the same logical path as the original .xcpj file. This file resembles the original except it only lists the public files of the project (this is achieved by simply assuming that everything under a directory named src isn’t public and therefore isn’t exported). It also inserts the keyword export into the exported version of the .xcpj file to flag it as exported.
When generating an MSVC solution that links against an exported library, it is possible to generate a utility .vcproj project file that conveniently allows the (read only) public header files to be viewed by the developer. This option is available through the solutionContainsPrepackagedProjects flag that can be assigned in a .xcpp configuration file (see section 5.1).
The Xcpp Build System sets up additional includes for the compiler that match the sequence of paths to the physical trees in the input virtual tree. When a programmer uses a #include directive to a public header file in a different project, a logical path to the header file is recommended. This will always bind to the appropriate file in the virtual tree.
Libraries typically define one or more public header files that are regarded as part of the output of the build to be exported. The Xcpp build system supports the copying of public header files from the input virtual tree to the output export directory. This is done without changing the relative path from the root of the virtual tree. Therefore public header files in the export directory have the same logical path as they do in the input virtual tree. This allows dependent projects to be build either against the original source code or else the packaged version with no need to worry about additional includes.