Re: [Boost-build] modular builds

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

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

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?

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