On 6/16/2015 6:01 PM, Rene Rivera wrote:Okay, but in that case Jamfile for your library needs to distinguish these cases?
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>.
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?