On 08/05/15 12:27 PM, Rene Rivera wrote:
>
>
> On Thu, May 7, 2015 at 5:58 PM, Stefan Seefeld <stefan@seefeld.name
> <mailto:stefan@seefeld.name>> 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 ?

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 ?