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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-28 02:39:35

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? 

Other comments. First, your suggestion using /foo/bar for a child Jamfile 
of /biz -- which is indeed a not realistic usecase. 

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

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

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

- Volodya