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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-28 10:34:54

On Tuesday 28 December 2004 18:14, David Abrahams wrote:

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

Yes, both are possible. 

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

I did not say that you suggested. In fact you said that arbitrary ids are not 
realistic, which I agreed to above.

> > 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'm asking what project id of libs/foo/Jamfile will be? Will it be p/foo, or 
something else?

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

We need to decide what to do in this case.

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

But it requires every child project to include "project" invocation, and it's 
not always needed. I've recently tried to convert to Boost.Build a large 
existing project. Each directory defines just one library. Now, each Jamfile 
looks like:

llvm-lib foobar ;

and that's all. I don't think requiring to define project id is good.

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

It surely will be great to fix this.

- Volodya