Subject: Re: [Boost-build] modular builds
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2015-05-08 13:23:23
On 08/05/15 01:18 PM, Rene Rivera wrote:
> On Fri, May 8, 2015 at 12:04 PM, Stefan Seefeld <stefan_at_[hidden]
> <mailto:stefan_at_[hidden]>> wrote:
> 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]>
> > <mailto: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
> > 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
> > 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
> exists, i.e. whether we are dealing with a full boost source tree.
> 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
> > <https://github.com/boostorg/predef/blob/develop/test/build.jam>..
> > From lines #9 through #39 are just dealing with the different
> > that exist. I barely understand the code.. Since Volodya wrote a
> > 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 ?
> Simple, and annoying, reason is because for the straight git checkout
> the headers (boost-root/boost) are not there IIRC.
Right. Well, but if we assume that the headers stay with their
respective module, and let the build system handle that case (by adding
one -I option per library), we have already got so much closer to the
stand-alone build use-case. :-)
Alternatively, we use the setup step that's already there (IIUC), and
which sets up symbolic links to create a single-rooted layout that boost
used before the modularization effort.
> 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 ?
> That would be wonderful :-) But I guess the question is.. How can we
> reduce the number of cases? Do we make the release tar balls mirror
> "exactly" the git checkout?
Would there be any reason not to ?
-- ...ich hab' noch einen Koffer in Berlin...
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk