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
Jamfile: project my-project ;
foo/Jamfile: project my-project/foo ;
Why "my-project" in the second Jamfile? Can we avoid the duplication and just
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.
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