Re: [boost] Cmake

Subject: Re: [boost] Cmake
From: P F (pfultz2_at_[hidden])
Date: 2017-06-24 17:12:02

> On Jun 24, 2017, at 12:02 PM, Stefan Seefeld via Boost <boost_at_[hidden]> wrote:
> 
> 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.)

Both school of thoughts are in disagreement about how to build their dependencies, and believe the other school of thought has lots of problems. Rather than boost try to pick just one(and alienate the other users), with cmake we can easily support both scenarios.