Boost logo

Boost-Build :

Subject: Re: [Boost-build] modular builds
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2015-05-08 13:04:44

On 08/05/15 12:27 PM, Rene Rivera wrote:
> On Thu, May 7, 2015 at 5:58 PM, Stefan Seefeld <stefan_at_[hidden]
> <mailto: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
> itself,
> You must be talking about some other boost.jam, not this one
> <>? Since
> that one is already part of BB.

Sorry, my bad. Yes, I was probably just tired and didn't realize that
the file already exists.

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

I guess a good predicate might be a check to see whether ../../../tools/
exists, i.e. whether we are dealing with a full boost source tree. (Yes,
it might still make sense to want to build stand-alone, so a
command-line option would be good to override that test, but it would be
a starting point.)

> If you look at the Predef test build file
> <>..
> 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?

Actually, why are there so many different layouts to begin with ? Why
doesn't it boil down to simply two:

* integrated: having the full boost source tree (no matter how you got it !)
* stand-alone: having only the library's source tree you are actually
interested in

In other words, why does it even matter how we get hold of a source tree
? Why is the layout of a source tree different depending on whether I
checkout via git, download a source tarball, etc.) ? Wouldn't it make
sense to first try to consolidate on a single layout, before adding
complicated build logic to deal with all those differences ?

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


      ...ich hab' noch einen Koffer in Berlin...

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at