From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-28 13:36:32
On Tuesday 28 December 2004 21:01, David Abrahams wrote:
> >> > 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?
> Actually I think this case is clear: libs/foo/Jamfile is a top-level
> project called /foo. libs/Jamfile is an unnamed project, and Jamfile is
> a top-level project called /p.
> Now if we change libs/foo/Jamfile to:
> project ../foo ;
> subproject foo ;
> project p/foo ;
> it should be an error. It's perfectly detectable. The next Jamfile in
> the directory tree above any named subproject must be named.
I don't see why this should be so. Maybe, I just miss what we're trying to
achieve. Are we trying to allow a project to declare id relatively to
parent's id? In that case:
project ../foo ;
makes sense to me.
Are we also trying to disallow a project to declare arbitrary id? If so, what
does it buy us? And I think that in the case above, it's possible to manually
specify p/poo, no matter what intermediate Jamfiles are there.
> >> > 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.
> That's a one-time investment for the rare case where you're converting a
> large project, so I think it's a tiny cost to pay compared to the
> conceptual overhead of requiring a funky special file at the top of a
> project hierarchy.
I don't quite agree. This investment is not for converting a project, it's
also for development. It means that whenever you define a new project, you
need to declare a project id. Also note that we planned the allow top-level
Jamfile to define a rule which maps project ids to directory locations. In
that case, all information about project ids will be contained in the
top-level Jamfile. What's the use of project id specified in a child project.
And if there's no use, why specify id at all?
> There's no precedent for that in any build system
> I've seen,
> and it's been a continual sort of mental friction from users.
> I remember that Ali had real problems with it,
IIRC, his primary problem was that even "hello" example needs *two* files --
Jamfile and project-root.jam -- and that's no longer required.
> and *something* recently
> spurred you to introduce Jamroot, which is just another expression of
> that friction.
That "something" was the fact that you could use some rules (like "constant")
only in project-root.jam, and some other rules (like "exe") only in Jamfile,
and it was confusing. With a single required file that problem is solved.
> As an alternative subprojects could just declare:
> subproject ;
> subproject . ;
> Or, we could simply require that top-level uses of the project rule all
> have ids. Any unnamed project will trigger a search up for a parent
So, a project is still is required to invoke the "project" rule, right?
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