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.