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

Subject: Re: [Boost-build] RFC: Rootless projects..
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2015-06-11 10:13:54

On Wed, Jun 10, 2015 at 10:55 PM, Steven Watanabe <watanabesj_at_[hidden]>
wrote:

> AMDG
>
> On 06/10/2015 08:15 PM, Rene Rivera wrote:
> > In trying to remove the roadblocks to standalone, aka modular, projects I
> > ran into one that should be easy to remove. In order to build a project a
> > "jamroot" is currently required. I'd like to remove that requirement by:
> >
> > 1. Allowing a jamfile to take the place of a jamroot (currently we allow
> > the inverse).
> >
> > 2. Make a jamfile without a parent project the jamroot for the project.
> >
> > Comments?
> >
>
> What precisely is the problem with just
> using Jamroot for the project?

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.

Boost Python would also like to operate in such a standalone mode for
development. And I want to support that model. But having the requirement
makes it harder for that support to happen as there extra steps the
developer and user have to do to create that jamroot.

In other words.. I would like to support getting one of the Boost
libraries, and assuming I have its requirements (both source and tools), I
can interact with it without changes. One example of such an interaction
would be running tests on cloud CI services.

> The only
> thing that we gain by making a child
> project is inheritance of project properties,
> rules, and variables, but if a project is
> able to build standalone, I'm not sure why
> this is needed.
>

I'm failing to understand that sentence.. Or if there's a question in there
:-(

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail