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