On 5/6/19 4:47 PM, Rene Rivera via Boost wrote:
Bringing this up because of the recent discussion in the 1.70.1 thread. And of course because this is the week that a certain BSC meets. Hence I thought I would clarify what I've meant my a modular Boost all this time.
A modular Boost, to me, means a Boost that first and foremost a collection of independently consumable C++ libraries.
Right That would have the following
aspects to it:
* An end user or library author can obtain a single Boost library of their choice and use it in their project, assuming they also obtain the appropriate dependencies of that library.
Check
* BoostOrg would not produce a monolithic, combined, merged, etc distribution.
I don't see it as necessary for Boost to give this up. That is, I don't see the current setup as conflicting with the ability to just download the libraries he wants.
* BoostOrg would produce collectively tested milestone modular distributions.
I don't think anything has to change here.
Sounds lovely right? ...I'll leave the discussion of merits to responses herein ;-)
I envision the construction of a tool which just goes to github and downloads a list of boost libraries. For each library the download process makes a simple transform to a standalone directory for that library. Similar to what the global distribution currently looks like except for one library at at time. This would be useful right away. In vinnies 1.70.1 situation, one could put this to use right away. a)the user changes the name of the current beast directory to beast-1.70. b)downloads the latest from the master into the new beast directory.
What would it take to reach that modular goal? Why do I keep saying we've been working on this for ages and ages? Briefly here's what it would take to get there (not in any particular order):
* Abandon the single header include tree. * Abandon the monolithic build infrastructure.
One would need a more "stand alone" tool for non-header only libraries. But I presume lots of users would just compile the *.cpp files into their app or build their own DLL. Ideally, the library package would/should contain a CMake script to do this.
* Ban relative use of inter-library dependencies.
I don't think that's possible. But I don't think that's necessary. The only thing is that a user would need to install the dependent libraries he needs. One could try to make a tool to do this - but I've argued that that is a fools errand. Rather than argue that any more. I could just imagine user does the following: a) Adds a boost header to his project. b) "installs" that header as above c) tries to build his project d) If something missing - call a) for the missing thing at the end of that process, he has a minimal subset of boost required to support his project. If someone has nothing else to do he could write a tool which does generates a list of dependencies for a given app as a text file. Then the user would do most of them in one shot. This would likely be an minor enhancement of BCP or similar program. But the result would be the same. BTW - the user already incorporates non boost libraries into his project using this same procedure. Ideally any dependency checking tools would work on these as well.
* Explicit declaration of inter-library dependencies.
I don't think this is necessary.
* Strict normalized library layout.
I don't think this should be necessary. But I'm aware that some libraries don't follow convention regarding header layout. So either those have to change or the "downloader" tool would have to smart enough to sort those out. I don't recommend the latter option.
* Remove, and ban, dependency cycles at the inter-library user consumable granularity.
I don't think this is necessary. If one is following a chain of headers rather than a chain of modules - there are no cycles.
There's probably more items that I've forgotten above. But this should be enough to converse about.
LOL - ya think? I think you're concept of "modularized boost" is at least broadly similar to mine. To summarize, the only things we would need: a) we need a tool to download/transform one boost library at a time. b) optionally, it would be nice to have a dependency listing tool. FYI this is more difficult than it looks since the user doesn't all the boost libraries on his machine. Such a tool would have to trawl the boost master on github or some oneline database of headers summaries. c) There would likely need to be separate directory - boost tools with a couple of things in it. Some stuff would be moved from boost root to boost/tools. So the user wouldn't need the root on his machine. d) A good written explanation for users who want to do this. What we don't need to do is re-organize current boost/development/testing etc. This is merely an alternative deployment concept. Boost developers would not be effected. That's it. just three or 4 simple things. And no disruption of current setup. Robert Ramey