From: David Abrahams (dave_at_[hidden])
Date: 2004-12-28 10:14:57
Vladimir Prus wrote:
> On Monday 27 December 2004 19:25, David Abrahams wrote:
>> >> project my-project/foo ;
>> >> would cause a search upward for a parent Jamfile, whereas
>> >> project my-project ;
>> >> would not.
>> > I don't agree. After all, project-ids are completely optional. I don't
>> > think we should go back to requiring use to specify the exact relative
>> > location of a project w.r.t. project root.
>> Did I suggest that the exact relative location should be required? No.
>> That would be almost pointless.
>> I'm only saying that if you have a project-and-subproject structure of
>> the kind that's currently created by having many Jamfiles beneath one
>> project-root.jam, it's reasonable to expect that Jamfiles in ancestor
>> directories also specify ancestory project IDs.
> 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?)
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.
> 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 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?"
>> > 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
>> >> I don't buy for one minute the tutorial's justification that the project
>> >> directory structure can be changed without rewriting any Jamfiles. One
>> >> typically doesn't have so many Jamfiles or restructure projects so often
>> >> that fixing these references is a big deal.
>> > Imagine for a minute that the project in question is boost. If there 10
>> > projects which used Boost, and one day directory organisation change,
>> > that will be a major hassle.
>> I can't think of any *reasonable* change to our project structure that
>> would significantly disrupt project IDs.
> 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.
-- 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