Re: [Boost-build] modular builds

Subject: Re: [Boost-build] modular builds
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2015-05-08 12:27:48

On Thu, May 7, 2015 at 5:58 PM, Stefan Seefeld <stefan_at_[hidden]> 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