Boost logo

Boost-Build :

Subject: Re: [Boost-build] RFC: Rootless projects..
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2015-06-17 14:02:31

On Wed, Jun 17, 2015 at 12:51 PM, Vladimir Prus <vladimir.prus_at_[hidden]>

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

It indeed does. And currently it's doing it a kludge to determine that.

> And if so, maybe we need
> a more explicit way to indicate that a Jamfile is usable standalone?

Sure. But how? The rootness of a project is currently determined before
loading. So putting something in the jamfile would not work, right? Which
would leave something outside, i.e. a file. Which the only viable option I
can see is having yet another project file whose name says I can be either
Jamfile or Jamroot? So now we would have three different kinds of projects.
Not sure this is a good direction.

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

Well.. For Predef I'm OK with that (even in non-Boost contexts). But I can
see someone not wanting this. Or at least wanting to control it. And all I
can think of is adding something to the project declaration that says not
to inherit the project/jamroot stuff above it?

-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams -
-- rrivera/ (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

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