Re: [Boost-build] modular builds

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

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.

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

Would there be any reason not to ?

        Stefan

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