Thijs van den Berg wrote:
A goal I have in mind is to give individual libraries clear personal identities and allow for fragmentation of boost.
What do you mean by fragmentation? Will such fragmentation affect users in any way? How so?
apt-get install boost-math and that that would result in my machine downloading some boost libraries so that I can use boost.math with my specific compiler on my specific
It would be nice if I could do: platform.
Boost could help debian packagers make that possible by creating modular releases. However, even without modular tarball releases, debian packagers can create split packages. However, that would require that packages can be split in a non-cyclicly dependent way. Anyway, the above niceness does not seem to be a goal of boost modularization currently, as you can see from reading this thread.
Part of the it is about a dependency tree,minimal requirements, but also about configuration / versions. I would not like it to pull in *all* of the boost respository. I imagine that at some point we could have e.g. a Boost.Math for C++14 fork and If I said I wanted that, then I would *not* get parts like <random> that have already been added to the standard. Boost could also solve that by staying monolithic and providing switches or include wrappers, but those solutions would be less intuitive.
Yes, boost could do these things. However, you will notice by reading this thread that these things (modularity from the users perspective) are non- goals currently.
Tell me how things are now in your words and tell me what your goal is.
My goals would be change boost from a single entity "the boost libraries bundle" to a platform hosting multiple identies "the platform where i can find e.g.Boost.Math" because I think it will make it easier to contribute, and easier to use. The most important change would be to change the single identity of the whole of boost (identity = the thing you install as a user, the thing you need to learn to use, they think you asses the quality of) to multiple indentities -one for each library of boost-.
This thread shows that these things are non-goals.
In my opinion these are some direction we *can* take now that we have focus on modularisation and dependency graphs
Yes, but apparently they are non-goals.
Thanks for responding and asking for clarification,
Thanks for your response too. I agree what you want would be nice, but what you want seems to be non-goals for boost. That's why I would like to hear from others why boost migrated to git. What goals or purpose did that serve? Did it only serve some goals for the developer perspective (ie, not any goals for the users of boost)? Thanks, Steve.