Cached build or incremental build? #396
Description
This is definitely an open-ended question.
When a project includes Thirdparty OpenSource projects into it's build, there is a reasonable amount of overhead that goes into building such dependents. While this has it's benefits (compatibility, debug symbols, control), the time spent in rebuilds can be considerably more than the developer's own work.
Target thirdparty projects are those that build an exportable SDK, i.e. has headers, libraries, dynamic libraries, etc.
This idea is to mark such thirdparty project build scripts as 'cacheable' (for want of a better name). These would then have their SDKs published to a separate root to the build root - why? so that the build root can be cleaned without affecting the cache.
This is somewhat analogous to specifying a prefix in autoconf, CMake etc.
Ideally, debug symbols would be hived off at the same time, so that if object files are blasted away (they will probably still be in the build root), there would still be link-back to the source code.
Future builds of the developer's project would then detect that there is a cached SDK in this separate directory, and use that, rather than starting up a build of the Thirdparty project itself.
This would be a little weird in the VisualStudio project sense, as the first pass would generate libs, but a second pass would ignore it. Not sure how that would work - perhaps there are multiple configurations generated? Debug All, Debug With Prebuilts, etc.
The really clever bit would be to enable switching between the two. For example, say you want to try out an edit to a Thirdparty project because you've forked it. So you need to iterate on its source code. You would need to switch back and forth. With the VS configuration idea, this would be possible.