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

Subject: Re: [boost] CMake, modular Boost, and other stories
From: mike.dev_at_[hidden]
Date: 2019-04-24 18:29:01

First of all, sorry for the mess in my previous mail.
I was on my mobile and the client I used has very strange ideas
about formatting. 

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Robert Ramey via Boost
> 
> 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.

There is a huge difference between not wanting half/a significant portion
of boost as an indirect dependency (that’s what I said) and wanting *none*
of boost as an indirect dependency (that’s what you are implying I said).

> > 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.

It means that if boost libraries no longer want concern themselves with
c++03 support, then most of the dependencies on libraries like mpl, move, 
smart_ptr, array, variant, static_assert, bind, tuple ... and whatnot 
could be eliminated by using standard library types or newer (more lightweight)
replacements instead.

> >     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.

Only if you can uniquely identify an appropriate repository only based on 
an include statement. You can't even do that reliably in boost without first 
scanning all the library directories. 

> 
> >     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.

What I meant was, that only tracking along transitive header includes is not
enough. As soon as you include a single header file from library A, you also 
have to consider *all* the source files of A. 

> 
> >     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.

What I meant was plain and simple that there are a lot of dependencies 
between different boost libraries regardless of what definition of 
"dependency" you are using.

You can use my BoostDepGraph utility from 
https://github.com/Mike-Devel/boost_dep_graph to show you only the 
dependency tree from a specific boost library based on tracking 
transitive includes of individual headers. More often than not,
the tree is still huge and full of libraries that would not be 
necessary in a post c++03 codebase.

Btw.: Serialization is imho not the problem here. If you remove
it from the dependency graph, the overall situation improves only
marginally (but still noticeable).