Subject: [boost] [next_generation][modularization] Is the community interested in creating a smooth path to a modularized Boost
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-05-31 10:18:32
I've started a new thread in response to Julian Gonggrijp post
[modularization] proposal and poll, as I would not answer directly to
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk