Subject: Re: [Boost-build] modular builds
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2015-05-08 13:18:28
On Fri, May 8, 2015 at 12:04 PM, Stefan Seefeld <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]>> 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>?
> > 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
> > <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
> > * Building in standalone modular development layout (what I do with
> > Predef of building/testing against a git clone of the boost super
> > * 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.
> 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
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
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