On Wed, Jun 17, 2015 at 12:51 PM, Vladimir Prus <vladimir.prus@gmail.com> wrote:
On 6/16/2015 6:01 PM, Rene Rivera wrote:

On Tue, Jun 16, 2015 at 9:41 AM, Vladimir Prus <vladimir.prus@gmail.com <mailto:vladimir.prus@gmail.com>> 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