Re: [Boost-build] RFC: Rootless projects..

Subject: Re: [Boost-build] RFC: Rootless projects..
From: Vladimir Prus (vladimir.prus_at_[hidden])
Date: 2015-06-17 13:51:28

On 6/16/2015 6:01 PM, Rene Rivera wrote:
> On Tue, Jun 16, 2015 at 9:41 AM, Vladimir Prus <vladimir.prus_at_[hidden] <mailto:vladimir.prus_at_[hidden]>> wrote:
>
>     On 6/11/2015 5:13 PM, Rene Rivera wrote:
>
>         The use case is one that I've run into since the git transition and doing Predef development. And recently I
>         also see it in the BPL development. For Predef my normal way to work on it is to clone *only* the Predef
>         repo as
>         it's an entirely standalone library (doesn't depend on anything). Then I have a jamroot file above the
>         cloned
>         Predef, as it's required to build anything with BBv2. It's easy enough for me to do this of course. But
>         I would
>         like to make it easier for *users* to just get the Predef library and say, run tests and build without
>         special
>         instructions or having the whole of the Boost super project. But at the same time I can't just include a
>         jamroot
>         in the Predef project because it would break (in silent and strange ways) when it's part of the Boost
>         super project.
>
>
>     Rene,
>
>     could you describe in more detail how you envision this feature to be used? While predef is entirely standalone,
>     that does not appear to be a typical case, so I think we need to decide how a typical case should work, and
>     optimize for that case.
>
>
> True, it's not typical at the moment..  But it's becoming more prevalent (slowly).
>
>     Say, a Boost library can be built either inside the tree, or outside the tree. In the former cases, it
>     automatically gets access to:
>
>     - Requirements from Boost's Jamroot
>     - constants
>     - helper functions
>
>     In the standalone case, how would a library access all that?
>
>
> Generally a non-standalone outside-the-tree library build (or test) would get that information from the "system"
> and/or from BB. Part of the information would come from the boost.jam module
> <https://github.com/boostorg/build/blob/develop/src/contrib/boost.jam>. Which might need to be extended to
> support more of the Boost helper functions. The goal would be to accommodate two cases: the standalone build as
> BPL wants (i.e. build against a system available Boost), and the testing build where we obtain the dependencies
> and perhaps use modular.jam to synthesize the dependencies
> <https://github.com/boostorg/build/blob/develop/src/contrib/modular.jam>.

Okay, but in that case Jamfile for your library needs to distinguish these cases? And if so, maybe we need
a more explicit way to indicate that a Jamfile is usable standalone?

> In other words the information would be either in the an available Boost or already in BB (boost.jam).
>
> Sorry I don't have any more detail than that. But I'm addressing issues as I try to get to the goal (i.e. the
> two use cases above).

The concern I have about the current patch is that things start to behave very differently depending on context.
Suppose I put predef into my project source, under externals/predef. Suddenly, it picks up my Jamroot, inherits
things from it, and possibly behaves differently?

- Volodya