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

From: David Abrahams (dave_at_[hidden])
Date: 2004-12-27 11:25:16

Vladimir Prus wrote:
> On Monday 27 December 2004 11:31, David Abrahams wrote:
>> Having read through all the Boost.Build documentation, I can't
>> understand why it's important to have this file/distinction anymore.
>> What is the point of searching upward for that file upon startup? It
>> seems to me that a more sensible approach would be to search upward for
>> parent projects of any project that declares itself to have a subproject
>> ID:
>>
>> 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.

>> The current situation where subproject IDs can be entirely unrelated to
>> project structure is highly counterintuitive. Why should this be possible:
>>
>> Directory Project ID
>> foo quanset/hut
>> foo/bar blackguard
>> foo/bar/baz old/socks
>> foo/bar/boo tired/horse
>>
>> ??
> 
> 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.

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

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