Subject: Re: [boost] Boost Evolution
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-05-17 17:00:38
> a) modular deployment and dependency management. No surprise here as
> this is a job of major, major difficulty.
> b) policy for library deprecation - not really hard but really very low
Just out of curiosity: is there a concept for this?
I have a few ideas for that:
Make the submodules targets in boost.build. That is, if I want to build
a submodule, e.g. 'b2 --with-filesystem' will also pull the submodule.
That would also apply for references, e.g. if I build boost.dll it will
automatically require the build of boost.filesystem, so if it references
/boost/filesystem, this will pull this one.
I have an idea how that could be implemented in boost.build (by
declaring the submodule/.git a target). I know that the --with-library
parameter only works for those with binaries, but that does not have to
be that way.
This would speed the CI build up immensely (currently most of them
checkout all submodules) and secondly allow partial deploys by just
setting a list of the submodules to be included in the build. That would
be the simplest form of package-managing (though source isn't really a
package) but would imho be rather easily implemented. Also the CI would
then test if the dependencies are set correctly.
Thus we could provide a version to build a partial set of the boost
libraries from github; if a downloadable archive should be provided it
would then also be possible to run bjam to just pull the submodules and
delete the empty ones, so we could provide a fast way to generate an
archive with the correct dependencies.
Now if this approach would work, it would be incredible easy to generate
your own package of boost, so it wouldn't be a big problem if some
libraries get deprecated. They wouldn't even have to be a submodule,
since adding a submodule is very simple. The build-system already
automatically searches the subfolders.
Secondly, as for the deprecation, I'd think the most obvious way to
group boost libraries is by the C++ Standard. So basically: boost.lambda
is not included with Boost-11, Boost-14 would include boost.hana, but
deprecate boost.fusion etc. The current would of course be boost-1z.
If an old version is than no longer maintained, well, if someone needs
it, he should maintain it. Would be easy enough with that approach.
That would mean: if a library gets deprecated, there is a replacement in
either the new boost version or the standard. We would however break
code, but since it's easy to setup a custom boost-config, you can
include the deprecated library in your own.
Thirdly, a <standard> parameter in boost.build would be nice (and easy)
and thus a library maintainer could better structure his library. Also
there could be an error if someone attempts to build a library with a
too old standard.
Additionally it could be differenciated between two versions of a
library, by having different 'master' branches. Though I haven't thought
that through yet, i.e. how that would be implemented in boost.build.
I think the build should then look like this:
b2 //builds the current version, i.e. boost-1z
b2 standard=11 //builds the 11 version
b2 standard=11 package-list=my_list //builds only whats in my_list
I think I can help with the boost.build implementation, but I would of
course be interested in what you think of those ideas.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk