Dominique Devienne wrote:

I'm not buying the CMake zealots who advocate for the "one true way" of doing it... --DD

On the contrary, I wish there were more clear directions about the "one true CMake way" of doing it, because at the moment there's definite shortage and everyone seems to treat CMakeLists.txt as their own personal playgrounds.

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