Stefan Seefeld wrote:
The workflow you promote...
Support. The word is support.
(as far as I understand it) builds (parts of) Boost as an integral part of a user project that depends on (parts of) Boost.
Exactly. This provides control over what exactly is built, the state of the entire project (the composition of dependency versions) is described by a single SHA, and it's easy to deploy.
The lack of modularity (and more importantly: encapsulation) here is exactly the same lack of modularity I deplore in Boost itself:
Fine. Don't use this workflow. The cmake files also support installation via CMake - that's number 3 in my list.
And the fact that some of Boost is header-only is entirely irrelevant to my argument. If there is nothing to build there is nothing to build.
There is something to build, it's just built as part of your project and is inlined into your code. If you build against Boost 1.53, you get Boost 1.53 embedded into your binary. If you build against 1.65 - 1.65. There is a way to encapsulate, it's called extern "C". Boost doesn't use it.