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 ;
>> 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
> which I agreed to above.
>> > 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 ;
subproject foo ;
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
> 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
As an alternative subprojects could just declare:
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
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk