From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-28 01:40:15
Ali Azarbayejani wrote:
> > Not exactly. I mean that "foo/bar" syntax still will mean
> > - file 'bar' in directory 'foo'
> > - target 'bar' declared in 'foo/Jamfile'.
> > I think the latter abilility is so handy so we should not drop it.
> but, if i understand correctly foo/bar is target bar in foo/Jamfile if
> foo/Jamfile exists and otherwise it is file foo/bar. no?
No. "foo/bar" is target in foo/Jamfile if foo/Jamfile exists and has target
called "bar". At least that was my intention.
> if so, i would still like to be able to have a workaround if i need to
> refer to file foo/bar when there is a foo/Jamfile. i suppose one way is
> to make foo/bar a main target...in fact, this was my workaround...but
> then i ran into the problem that i could not use "foo/bar" as a target
> id (because it has a slash, and project.find-target won't find it), so i
> couldn't have my main target...it got really ugly and there is currently
> no workaround without patching the BBv2 codebase.
Just to clarify: did you have to use "foo/bar" because file "bar" in directory
"foo" was not found? Your posts did not contain an example of *this* problem.
I believe there's no other need to use main target names with slashes?
> question: how do you refer to target "foo/bar" in project "my/lib"?
There's no way, but also, IMO, no need to name target "foo/bar".
> look, here's the problem...there's basically two ways to refer to a
> file: (1) filename or (2) project/target id. since filenames can have
> slashes in them, any syntax for target ids that uses slash to separate
> projects from targets is going to run into ambiguities. so my
> recommendation is to drop the use of slash to delineate target from
> project...it doesn't even look very clear when you write foo/bar that
> "foo" is one thing (project id) and "bar" is another completely
> different thing (target id).
I think that if main target name cannot contain slash, you get ambiguiity only
in the last component of "foo/bar". Here, the interoperability of main target
name and file name seems a good idea.
> how about the following?
> <filename> (file relative to this project...or absolute)
> <target> (target in this project)
> @<project> (location or id of other project)
> @<project>@<target> (target in other project)
> @<project>@<filename> (this could be allowed too: file relative to
> other project)
If it were not for the last use case, your proposal would be very similiar to
what we have now. Isn't this use case just another over-generalisation. I'm
proposing to disable some syntax now, because it's of now use. And you
propose yet another feature :-)
I'm -1 on the last syntax. Projects referred by @ syntax must be standalone
isolated entities. IOW, they export only main targets, and nothing else, and
don't allow clients to wander through their source tree.
Imagine that a single project "@lvk" can be available in two ways. First way
is regular source tree. Second way is a single Jamfile, which defines a bunch
of prebuilt targets. In the second case, @lvk_at_foo/bar.cpp will simply break --
because this syntax is like accessing private members in C++.
> is there anyplace where there is a concise syntactical description of
> these id's? i see a number of examples in new/boost_build_v2.html, but
> i can't find a definitive specification.
even contains something like a grammar.
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