DEP2

Separate compilation and caching of dependencies

Basic build algorithm

...

Directory structure for cached builds

packagedir/.dub/build/<build-id>/<targetname>.<ext>
packagedir/.dub/build/<build-id>/<targetname>.o

Trigger a new build when any file in a package is newer than the cached binary.

When building a package using "dub build", the build is first performed in the ".dub/build" directory, followed by a copy of the target binary to the "targetPath".

Construction of the build-id

Several build properties affect the outcome of the final binary. All of those must be encoded in the build-id. These are in particular:

• All version identifiers (upwards and downwards inherited)
• Version and debug level (currently not supported by DUB)
• All debug version identifiers (upwards and downwards inherited)
• All build type relevant flags, inherited by top-level package (-g, -debug, -unittest, -cov etc.)
• Linked libraries (only for the package itself)
• Included source files (only for the package itself)
• Import directories and string import directories (only for the package itself, but this makes hygiene assumptions about packages)
• Target architecture (specific for build run)
• Compiler (specific for build run)

Since it is impractical and undesirable to directly list all of those properties in the build-id, there are some possibilities to get a more managable build-id:

1. Use a hash digest over all relevant properties. This will yield an opaque ID that is unique for each build configuration and can be reused for different dependency trees that have the same properties, but will also result in a new build-id for every change and in turn to a new build folder

   .dub/build/acbd18db4cc2f85cedef654fccc4a4d8/
   

2. use the name of the selected configuration, build type, compiler and architecture and perform a hash digest over all version identifiers and build type flags inherited from upwards the dependency graph. This offers at least a partially readable build-id and still guarantees a practical length of the ID.

   .dub/build/metro-debug-x86-dmd-acbd18db4cc2f85cedef654fccc4a4d8/
   

   Note that since the build type is already encoded in the hash value, it's mentioning is redundant, but may be nice to be able to quickly locate the right folder.

3. Do the same as for number 2, but don't hash the inherited part. This will usually result in much longer, but human readable IDs. The utility of such a fully human readable tail, however, seems questionable. An alternative may be to put a text file with this information into the build folder.

   .dub/build/metro-debug-x86-dmd+-g+-debug+-version=VibeWin32EventDriver+-version=Foo+-version=Bar/
   

Of the three, method number 2 is chosen for its good blend of properties.