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

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]>
wrote:

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

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 - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail