Boost logo

Boost-Build :

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

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

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at