Andrey Semashev wrote:
1) Why does mplcore exist? Why is its content not in core?
Because it has a distinct set of functionality which may not be needed by a Core user.
Pick any two things in core. One of them might be needed by some user of it while the other is not.
Merging MPL.Core with Core would make Core heavier and add more dependencies to it, which contradicts its incentive.
... or it could consume those dependencies (or at least be in the same repo and the same modularized release tarball) and really be core.
4) Why is static_assert not part of core? What is the value of it being seprate?
Frankly, I would merge it with Assert or Config, although I did not analyze reports to see the consequences. In any case, it's a leaf library, so it doesn't add much.
What do you think the term 'leaf' means? What the separation 'adds' is extra/different/separate things you need to have/get before you can use a higher-level library.
5) What if core actually contained 'core stuff'? What if core contained 'toolchain normalization' (such as static_assert emulation, a BOOST_STATIC_CONSTANT macro, etc) and facilities essential (ie, core) to the rest of boost?
The problem is that the set of "essential facilities" differ from one Boost library to another. Some only needs Config, other need stuff from Core and Preprocessor, third require MPL, TypeTraits and Utility.
True...
The solution is to make multiple such fundamental libs, each implementing its part of common functionality and having minimal dependencies.
Leading to the apparent 'ideal' of one class per library. An alternative solution would be to group the (small amount of) fundamental stuff together in one repo/library. That's at least what QtCore does, for example. It doesn't matter if two classes within it are technically unrelated. The suggestion is providing a one-stop-shop (download tarball or repo) for the core stuff which between 60 and 88 of the libraries in boost use, because it is 'core'. Then the challenge is balance between keeping it small enough and keeping it relevant enough (by actually having core stuff in it).
6) What if core was bigger? What if using boost library Foo only required me to download/install boost core and a *small* handful of other *independent* (not interdependent, as most of boost is now) dependencies in order to use it? This trend of creating tens of tiny 1/2/3 file "libraries" and "sublibs" runs/sprints against that kind of scenario.
This would be a step towards monolithic Boost.
No, not really. It would be analysis of what the core stuff is, and then grouping that core stuff together. A dependency on Boost.Core should not be a problem and should provide core stuff. Boost.Core should be designed so that that is true. [Aside: current boost is not much less monolithic than it was in svn. It's released/downloadable monolithically]
What if my library only needs BOOST_ASSERT? Do I have to pull half of MPL and TypeTraits along in this "bigger core"?
Yes. You as a developer would install boost-core.git or boost-core.tar.gz and then you would develop mylib, whatever it is. A user could download/install boost-core.tar.gz and mylib.tar.gz instead of boost-mplcore.tar.gz, boost-static_assert.tar.gz and boost-assert.tar.gz before getting to mylib.tar.gz. Very little depends on only one of these 'low level' libraries.
As I see it, the problem with the current state is not the amount of core libraries but the unnecessary transitive dependencies they impose. It's not a problem to download Core and MPL.Core separately, as long as these libs don't require much themselves (like Utility or TypeTraits, for example).
Similarly, if they don't require much themselves (and if most dependers use both of them), it's not a problem to combine them. Thanks, Steve.