Re: [jamboost] Target id syntax

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

http://boost.sourceforge.net/boost-build2/boost_build_v2.html#targets

even contains something like a grammar.

- Volodya