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

Subject: Re: [Boost-build] RFC: Rootless projects..
From: Vladimir Prus (vladimir.prus_at_[hidden])
Date: 2015-06-17 14:19:54

On 6/17/2015 9:02 PM, Rene Rivera wrote:

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

Yep, clearly having yet another file won't be great. But maybe your idea below will help...

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

We probably can start with easy thing - say a library X want to use Boost.Thread, and uses /boost//thread to 
refer to it.

In that case, inheriting definitions if there's Jamroot above is actually reasonable. Inside Boost, /boost will
be inherited from Jamroot. Totally outside, that will have to be specified, and we have have code like this:

        if [ target-not-known /boost ]
         {
                if $(BOOST_ROOT) {
                        using /boost : $(BOOST_ROOT) ;
                 } else {
                        errors.error "We're used outside of Boost tree and BOOST_ROOT is not set" ;	
                 }
         }

Inside my project, I can either "use-project /boost" in my project's root, or set BOOST_ROOT in
environment. It probably does not hurt to inherit constants or functions either - and those
can be easily overridden. However, requirements seem scary - in part because their change
compilation options, and because we can't ask not to require them. Maybe, all we need
is a way to suppress inheriting *any* requirements?

- Volodya