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

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 ;

or

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
elegant.

>> >> 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