From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-28 10:34:54
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. In fact you said that arbitrary ids are not
realistic, 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
> > I think it's possible to drop Jamfiles
> > without any id, just with requirements, between two other Jamfiles with
> > explicit ids, and we need to do something.
> What do you mean by "we need to do something?"
We need to decide what to do in this case.
> >> > I don't know, the names don't make any sense indeed. However, I also
> >> > don't know why we should prevent a project id to be "libs/ipa", even
> >> > if Jamfile is located in "libs/Optimization/Scalar/ipa" directory.
> >> Re-read what I wrote, and don't be so quick to argue this time ;-). I
> >> would never suggest preventing that. If the search fails to find a
> >> Jamfile in libs/Optimization/Scalar that declares a project "libs," the
> >> search continues upwards until it does find such a Jamfile, most
> >> probably in the libs directory
> > 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
llvm-lib foobar ;
and that's all. I don't think requiring to define project id is good.
> > Oh.. well. I think "tutorial justification" is actually justification for
> > using project ids as opposed to directory names. It's not a justification
> > for using arbitrary ids.
> The problem is that the tutorial *does* use confusingly arbitrary IDs,
> so it appears to justify that practice.
It surely will be great to fix this.
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