[next_generation][modularization] Is the community interested in creating a smooth path to a modularized Boost
Hi, I've started a new thread in response to Julian Gonggrijp post [modularization] proposal and poll, as I would not answer directly to his questions. I'm sure that almost all of us want a modularized Boost. What does this means? It is up to us to define it: * what the user can request as a delivered package for its own needs? * what the authors must state explicitly? * what must be tested/checked? The main problem is how to achieve it ensuring backward compatibility . I'm persuaded that we need a new Boost repository (or whatever we want to name it) that would include libraries that respect the modularization constraints we could define. My question is who would be interested in starting the next generation of a modularized Boost that starts from a repository of ZERO modularized libraries. The idea is to add to the current Boost libraries new ones that respect the modular rules and adapt the current ones to be defined on top of the modularized ones. At the end we could deprecate the old ones. In order to do that we need of course to add new interfaces (a new namespace mod_boost or whatever is preferred) and so the user would need to move to these interfaces smoothly. Before starting we need to * Define the constraints of a modularized system - no cyclic dependencies, .... * Define the tools that can be used to support the modular system - which build system(s), - which test system(s), - which regression system(s), - which doc system(s), ... * Define the rules - who could be able allowed to do the refactoring? - Should the refactoring be reviewed to ensure a improvement on the quality of Boost? - who maintains what?, ... * Setup the infrastructure ( build system, test system, regression system, doc system, ... ) Only then we could * Start from libraries that don't depend on any other library (with possible refactoring) and adaptation of the refactored libraries from which these modular libraries have been extracted. * Deliver them * Build a second layer of libraries that depend only on first layer * Deliver them * ... Of course, in order to check that the rules and tools are the appropriated ones we will need to experiment with some examples. I recognize that this would mean a lot of work, however I hope that the final result would satisfy better the community expectations and the quality of Boost libraries. Best, Vicente
On 31 May 2014 at 16:18, Vicente J. Botet Escriba wrote:
I'm persuaded that we need a new Boost repository (or whatever we want to name it) that would include libraries that respect the modularization constraints we could define.
Apart from the lack of requiring C++ 11 as a minimum, and that everything be formally packaged as C++ Modules ready for 17, this is pretty much identical to what I proposed as a fork.
I recognize that this would mean a lot of work, however I hope that the final result would satisfy better the community expectations and the quality of Boost libraries.
Whilst not as ambitious as what I proposed, your proposal is plenty sufficient Vicente to in my opinion reinvigorate Boost. And it is a good compromise for those in the 03 camp. I don't think the work involved is the problem. It's motivating people to give up time with their families to work on Boost. Solve that and you cure the disease. I support your proposal. I agree a document laying out the structure of a new empty repository is the first step. Who will volunteer to work on such a specification document? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Le 31/05/14 16:18, Vicente J. Botet Escriba a écrit :
My question is who would be interested in starting the next generation of a modularized Boost that starts from a repository of ZERO modularized libraries. The idea is to add to the current Boost libraries new ones that respect the modular rules and adapt the current ones to be defined on top of the modularized ones. At the end we could deprecate the old ones.
In order to do that we need of course to add new interfaces (a new namespace mod_boost or whatever is preferred) and so the user would need to move to these interfaces smoothly.
After some thought the change of namespace is not really necessary and even make things more difficult. At the source level we only need to move the source to other files and include them. I don't know how to make this transition without a breaking change. Best, Vicente
participants (2)
-
Niall Douglas -
Vicente J. Botet Escriba