On 24.06.2017 12:29, Peter Dimov via Boost wrote:
Stefan Seefeld wrote:
To be honest, I don't quite understand 2). Why do you want to support building boost (or parts of it) as an integral part of something else ?
That's a common workflow. Your (non-Boost!) library or project keeps all of its dependencies in ext/ and "consumes" them from there using add_subdirectory from CMake. This is what boost-cmake-demo-2 shows. This is not a way to support building Boost, this is a way to support using Boost libraries as part of some user project, without needing to build and install (the entire) Boost.
Modularity and encapsulation doesn't seem to have any value to you, or does it ?
Not sure what you mean here. You ask me why do I want to support building only parts of Boost,
No, that wasn't my question.
then ask me whether modularity has any value to me. You must be using a meaning of the word "modularity" with which I am not familiar.
The workflow you promote (as far as I understand it) builds (parts of) Boost as an integral part of a user project that depends on (parts of) Boost. The lack of modularity (and more importantly: encapsulation) here is exactly the same lack of modularity I deplore in Boost itself: Rather than building, packaging, and testing the different components independently of one another (and then let them "consume" the prerequisites as pre-built entities), you promote building everything as a single monolithic entity. While I can see that some people would like the extra control that provides, I also see lots of problems with this approach. (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.) Stefan -- ...ich hab' noch einen Koffer in Berlin...