Re: [boost] Boost Evolution

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
> priority.

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.