From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-07-15 08:59:44
David Abrahams wrote:
> > 2.1 2.1 The name of a target should be exactly the name specified in
> > project referred by the part before "//"
> When you say "specified" you mean "by calling the 'project' rule" as
> described below.
> > Yea. The question is if we want to just remove the leading slash, or
> > allow relative project ids. The latter approach seems better -- while I
> > never lacked relative ids much they would make the syntax more
> > "complete".
> A possible problem is that if you allow relative project ids you then
> have no way to explicitly refer to a Jamfile via a path in the
> filesystem that happens to match a project id.
Ehmmm... you're right.
> > We sure can make declaring ids relative to parent work. I might do it
> > rather quickly if we decide it's needed (though I might decide to
> > refactor project.jam at the same time)
> I'm trying to suggest that projects should never have to declare
> their own ids. That will make it much easier to write portable and
> interoperable Jamfiles.
Maybe I'm starting to get your idea, though I need to digest it more. I'm not
yet sure why current Jamfiles are not portable or interoperable.
> > OTOH, in either case 'use-project' would need full id if you want to
> > refer to specific project.
> > use-project /boost/python : some-path
> Not if you had
> use-project /boost : some-path ;
> and in boost's Jamfile some mechanism like:
> locate-subprojects libs/\\1/build \\1 ;
> There are several advantages here:
> for one, there's no need to work around top-level project id
> conflicts, because each project establishes its own notion of where
> other top-level projects are.
You mean, that project in 'some-path' does not declare project-id, or
that /boost specified in 'use-project' overrides whatever was specified
> for another, much less maintenance when new projects are
Yea, though with a mechanism to find all children project it's less important.
> More later.
Do I have to expect another email? ;-)
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