On Mon, May 4, 2015 at 10:50 AM, Stefan Seefeld <stefan@seefeld.name> wrote:

Indeed. Is there a better way to approach this ? If boost.python (as
well as most other libraries, I'd assume) depend (at least implicitly)
on boostcpp.jam, shouldn't that dependency be made explicit by having
another module / component "own" it, such that boost.python can then
depend on it ?

It seems to me that for the last couple of years people have been
arguing about modularizing boost with a very narrow focus on things like
header dependencies and source tree layouts, when there are many other
issues to be resolved.
How useful is it to hold individual boost libraries in distinct git
repositories, if I still need to check out the entire boost repo
including its submodules, to be able to build an individual library ?

Because of some external needs I started on a method to build Boost libraries without needing to do that full checkout. But obviously you would need to git clone the individual repos of all the dependencies. They BB support for this is in <https://github.com/boostorg/build/blob/develop/src/contrib/modular.jam>. Using it looks something like this:

=== Jamroot.jam

import modular ;

# Adds location to search for /boost/* lib references..

modular.add-location libs/boost /boost ;

# Adds external (to lib build files) dependency references..

modular.external /boost/config : /boost/predef//library ;
===
=== Jamfile.jam
import modular ;

exe my_program :  [ glob ../src/*.cpp ] /boost/config//library

  /boost/system//boost_system ;

===

All that it expects (or at least the goal is this) is that you have the needed libs in the search path as specified in the modular.add-location calls. Everything else should be handled. This doesn't currently doesn't handle the Boost tagging names stuff. As my use case only needed direct BB building.

Does this look like a better direction?