On Thu, May 7, 2015 at 5:58 PM, Stefan Seefeld <stefan@seefeld.name> wrote:

Hi Rene,

just a little follow-up to confirm that I was able to build boost.python
stand-alone by cloning the boost.jam file into the boost.python toplevel
directory and making some minor adjustments to the build files (adding a
Jamroot, and making minor changes to the "tag" rule in Jamfile.v2).

Why did you need to copy boost.jam to your project?

Obviously, this can't be the real solution, so the next question is what
to aim for in terms of package dependency. If boost.jam can't be part of
boost.build itself,

You must be talking about some other boost.jam, not this one <https://github.com/boostorg/build/blob/develop/src/contrib/boost.jam>? Since that one is already part of BB.

perhaps there could be a boost core module
containing hat file (together with some "core headers"), which all other
boost libraries may then depend on.

You'll have to explain in more detail why you think you need that.

Also, is there a way to support both this new modular build use-case as
well as the original integrated build ? While I have modified the build
logic in my local clone of boost.python, it would be best if I could
push those changes upstream, without breaking the existing build workflow.

Right. This is a problem that I ran into with Predef also. And what I do in it is nasty and needs to be better. In the case of Predef it is slightly different as it doesn't depend on anything else and there's no build involved. But I still had to detect between the standalone modular build and the integrated build. If you look at the Predef test build file <https://github.com/boostorg/predef/blob/develop/test/build.jam>.. From lines #9 through #39 are just dealing with the different layouts that exist. I barely understand the code.. Since Volodya wrote a good chunk of it. So the short answer to your question is..

There's currently no good way of telling in the library what context it's being used in. Hence we need some common code for that.

AFAIK we need to detect the following modes:

* Building in integrated development layout (i.e. what you get from cloning the "boost" super project).

* Building in integrated release layout (what users get in the tar balls).

* Building in standalone modular development layout (what I do with Predef of building/testing against a git clone of the boost super project)

* Building in standalone modular installed layout (your current use case)

* Building in standalone modular release layout (like you use case, but having a boost tar ball tree)

That's a lot figure out.. And a key question before trying to write code for detecting that is.. Which of those do we want to allow in the first place?

On an easier note.. We also need to add BB support to build without needing a Jamroot file so that we can commit the changes without having to remember to track a project external Jamroot file (for Predef I place a jamroot above the git cloned tree, for example).

-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail