Re: [boost] CMake, modular Boost, and other stories

Subject: Re: [boost] CMake, modular Boost, and other stories
From: Robert Ramey (ramey_at_[hidden])
Date: 2019-04-24 16:04:23

On 4/24/19 12:12 AM, Mike via Boost wrote:
>     > Hmmm - so no boost library should include any
>     > other boost library? Does  that seem a good idea?
>     Please don't put words in my mouth. I didn't say that
>     and you know it. 

Hmmm I was responding to the comment
 >       >when I just want to use
 >       > library X, the rest of boost doesnʼt come as a
 >       > dependency with it.
I don't know any other way to read it.

But the dependency graph could
>     easily be significantly simplified once c++03 is no
>     longer a concern. 

Hmmm I'm not sure what "no longer a concern means" in user code, in 
library code or ???.  In any case, I don't think more/less C++03 will 
not affect this issue.

Again: I'm talking about the
>     future, not the current state.
>     Just an example: [1]Boost.TypeErasure depends on
>     [2]Boost.Thread(and all that entails), just because
>     somewhere in its bowels it needs a mutex.
>     > It's always been good practice to not repeat/copy
>     > functionality in one library into another.
>     Not always. A recent example I stumbled over:
>     Boost.Signal2 depended on boost multi index (which
>     itself depends on a lot of other libs) because it
>     reused it's scope guard implementation
>     (IIRC about 50 lines of straight forward code).
>     Tying yourself to another library for something
>     trivial like that should not be a no-brainer.

>     > But what is really needed - and it may already exist
>     > in BCP but hasn't been promoted is a simple tool:
>     > a) start with one's application
>     > b) run the app through a tool which recurrsively
>     > reads headers
>     > c) and creates a list of all headers needed
>     > d) extract library names from that list
>     > e) add the git repo of those libraries to my apps
>     > project.

>     So boost should not only get its unique build system, but also its
>     unique dependency management tool?

Such a tool would not be tied to boost.  The issue of dependency affects 
all large programs.  Such a tool as described would be useful to any 
large project.

>     I can tell you as a user: Thanks but no thanks.

LOL - Sure - it's a free country.

>     Also: Didn't you forget source files somewhere in
>     there? What about tests?

The above describes the scenario in which such a tool would be used to 
support the tracking of dependencies in any large project.  If this 
project was one small app - the procedure would apply to just that app. 
If the one wanted to includes a test suite - the procedure would be 
applied to the union of all the programs in the test suite.

>     Bottom line: If boost as a whole was developed as a single project with
>     some coordinated devlopment
>     goal and strategy , it would make sense to distribute
>     it as a single package/framework and a single
>     cmake config file. 

>      It seems to me however, that it
>     is more a (huge) collection of independently
>     developed libraries, so I think it is more appropriate
>     to treat them as such

Absolutely.

>     even if there is a huge amount of coupling between them.

Hmmm - this is the rub.  The coupling is supposed to be narrow through 
type and function interfaces exposed in header code.  (to a lesser 
extent it extends to separately compiled library code as well.)  The way 
to deals with this is to keep the interfaces narrow.  I believe that 
Boost libraries actually do do this.  It's the framing or notion 
dependency in terms of library rather in therms of headers which leads 
us in the wrong direction.

> References
> 
>     1. http://Boost.TypeErasure/
>     2. http://Boost.Thread/

Although this problem is most frequent with the serialization library, 
it occurs with other libraries also.  In some communications, they are 
referred to as "glue libraries" or "bridge libraries".  It might help if 
this notion was formalized in some way.

Robert Ramey