Export folder

Exporting targets

Typically when a DLL is formally packaged and released only the following files are exported:

• The public header files
• Documentation of the API, perhaps with demonstration programs.
• The .lib file, which is needed when static linking to the library
• The .dll file.

A potential disadvantage to a client is that they cannot easily debug into the DLL without the original source code. Furthermore the client has in effect only been granted read access to the DLL, because without the source code they cannot make changes to the source code and rebuild the DLL. Nevertheless, a formally released DLL is very common and has a number of advantages:

• Space efficiency - no need to provide all the source code, supporting unit tests, design documentation etc.
• Hiding of intellectual property
• Clients don’t need to compile the DLL
• Helps to define formal releases that have passed quality control (i.e. release engineering)
• Developers have very clear boundaries, and more importantly well defined areas of responsibility. When development of a library is shared across hundreds of developers there is a tendency for no-one to take responsibility for quality.

This choice is particularly relevant to very large teams of developers. Should they use solutions that allow all source code to be built by all developers, or should packaging and releasing of DLLs be formalised internally within the team? For very large companies the latter approach must be employed to some degree because having every developer build all the source code isn’t scalable.

MSVC .vcproj and .sln files are influenced by this choice because there is a distinction between explicit linking to a given .lib file versus declaring a dependency between projects. By contrast the Xcpp build system makes this choice orthogonal to the representation of the .xcpj and .xcws files. Therefore the same files can be used to either build a large solution containing all the source code, or else a smaller solution where some of the projects don’t appear, instead using explicit linking to the released .lib files.

Multiple repositories can hold the same exports

Only one entity (e.g. a company or a developer) will formally export version X of library Y. Therefore everyone in the world should be able to agree on what that export actually is. It is therefore appropriate to check-in a given export into any number of distinct source code repositories. It shouldn’t create confusion because they should all be identical. This is important to allow for a given repository to be self sufficient or autonomous (e.g. to allow developers to build software despite only having access to a single repository).