Re: What is the point of project-root.jam/Jamroot?

From: David Abrahams (dave_at_[hidden])
Date: 2004-12-28 13:01:44

Vladimir Prus wrote:
> On Tuesday 28 December 2004 18:14, David Abrahams wrote:
> 
>> > Let's see. First of all, why child Jamfile should declare parent id, in
>> > this case. Say,
>> >
>> > Jamfile: project my-project ;
>> > foo/Jamfile: project my-project/foo ;
>> >
>> > Why "my-project" in the second Jamfile? Can we avoid the duplication and
>> > just inherit it?
>>
>> Sure. There are two reasonable ways.
>>
>> project ../foo ;
>>
>> or
>>
>> subproject foo ;
>>
>> (shades of v1?)
> 
> Yes, both are possible. 
> 
>> But note that your "drop id-less Jamfile between two id'd Jamfiles" case
>> below is harder to do error-checking for in this case.
>>
>> > Other comments. First, your suggestion using /foo/bar for a child Jamfile
>> > of /biz -- which is indeed a not realistic usecase.
>>
>> ?? I don't believe I ever suggested that.
> 
> I did not say that you suggested. 

Well, what you actually said doesn't quite work in English, but the
closest thing I could make of it was to add one word: "your suggestion
_was_ using /foo/bar for a child Jamfile of /biz," which means I
suggested it. Combine that with the fact that I never mentioned "/biz"
anywhere and I think you can see why I was confused.

> In fact you said that arbitrary ids are not 
> realistic, 
> which I agreed to above.

Okay.

>> > Second, what if I have:
>> >
>> > Jamfile: project p ;
>> > libs/Jamfile: project : requirements .... ;
>> > libs/foo/Jamfile project foo ;
>> >
>> > Will libs/foo/Jamfile have if of p/foo?
>>
>> Sorry, I can't begin to parse that sentence.
> 
> I'm asking what project id of libs/foo/Jamfile will be? Will it be p/foo, or 
> something else?

Actually I think this case is clear: libs/foo/Jamfile is a top-level
project called /foo. libs/Jamfile is an unnamed project, and Jamfile is
a top-level project called /p.

Now if we change libs/foo/Jamfile to:

project ../foo ;

or

subproject foo ;

or

project p/foo ;

it should be an error. It's perfectly detectable. The next Jamfile in
the directory tree above any named subproject must be named.

>> > Ok, I think I've recalled the problem which causes need for a different
>> > filename at top-level. You say that we load Jamfile and see what project
>> > id it defines. But, a parent Jamfile may define constants and rules which
>> > should be imported into child Jamfile, *before its loaded*.
>> > So, we need to decide if
>> > Jamfile has a parent using only the name. Now, if file is called Jamfile
>> > we try loading parent, and if it's called Jamroot, we don't.
>>
>> There's no reason a child Jamfile should expect to be able to use those
>> constants before it declares a subproject ID, and declaring a subproject
>> ID could be enough to cause the parent project to be loaded. Simple and
>> elegant.
> 
> But it requires every child project to include "project" invocation, and it's 
> not always needed. I've recently tried to convert to Boost.Build a large 
> existing project. Each directory defines just one library. Now, each Jamfile 
> looks like:
> 
> llvm-lib foobar ;
> 
> and that's all. I don't think requiring to define project id is good.

That's a one-time investment for the rare case where you're converting a
large project, so I think it's a tiny cost to pay compared to the
conceptual overhead of requiring a funky special file at the top of a
project hierarchy. There's no precedent for that in any build system
I've seen, and it's been a continual sort of mental friction from users.
I remember that Ali had real problems with it, and *something* recently
spurred you to introduce Jamroot, which is just another expression of
that friction.

As an alternative subprojects could just declare:

subproject ;

or

subproject . ;

Or, we could simply require that top-level uses of the project rule all
have ids. Any unnamed project will trigger a search up for a parent
Jamfile. If none is found we can issue a warning and continue. A
slight loss of efficiency and a warning is all that people will
suffer... but then they'll fix the problem and move on.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com