From: David Abrahams (dave_at_[hidden])
Date: 2004-07-14 08:58:07
Vladimir Prus <ghost_at_[hidden]> writes:
> David Abrahams wrote:
>> > Ah... I understand what you mean. No... the symbolic project id is always
>> > absolute:
>> > /boost
>> > /boost/date_time
>> > or something like that. If you're in /boost/date_time, then you can't
>> > refer to /boost by using ".." -- this is feature idea which never occured
>> > to me.
>> That's not what I mean.
>> If boost has been given an absolute project ID of /boost, I want to
>> be able to write something like:
>> to refer to the python library's test project -- though I would strongly
>> prefer to have a clear distinction between project path elements and
>> filesystem path elements:
>> or something
> Ouch. It seems you're asking fore even more complex syntax.
I'm asking for an explicit syntax. The semantics of the current
syntax are way too vague.
> What we have now
> 1. Target-id is either file or target in Jamfile
> 2. If it's target in Jamfile, it can be in the current Jamfile, or elsewhere
> 3. If it's elsewhere, we can use either filesystem path to refer to location
> of other Jamfile, or its symbolic project id
That's only half the summary. You haven't described how the syntax
is interpreted to yield those semantics (except in a bunch of
incomplete fragments from prior messages). Gather it all in one
place so we can look at it.
> What you propose that
> 4. It's possible to refer to other Jamfile using first symbolic project id and
> then filesystem path relative from that.
What I propose is that:
project IDs are bracketed (or something).
filesystem paths are un-bracketed
We probably also need some way to clearly denote a target name within
a project (as opposed to a filename). Possibly target names should
also be bracketed.
> I don't think I immediately like the latter idea because we'd really need some
> new syntax, e.g.  that you've used. I think it's not that hard to specify
> ids like /boost/thread in individual library Jamfiles.
The problem is *not* that it's hard to specify the id. The problem
I can't understand what the specifications mean!!
>> In fact, for Boost in particular, it would be nice to be able to say
>> something in a Jamfile about how to find its subprojects:
>> rule subproject-path ( subproject-name )
>> return libs/$(subproject-name)/build
>> So that once [boost] is identified, [boost/python] automatically
>> identifies the python subproject.
> It would be nice, but I think manual specification is acceptable.
I don't. How do I refer to the boost/python project from a project
unrelated to Boost?
>> > I'm not sure I understand. When looking up
>> > /boost/date_time
>> > in
>> > stage dt : /boost/date_time ;
>> > we first check if symbolic name /boost/date_time is known. If not, we try
>> > looking at *directory* /boost/date_time and check if there's Jamfile in
>> > that directory.
>> You can't answer my question without considering paths with more
>> exe foo : /boost/foo/bar ;
>> do you look for both /boost/foo//bar and /boost//foo/bar?
> I don't understand. The /boost/foo/bar refers to *project*. Two other syntax
> refer to targets in some projects. There's no way they can be equal, and
> naturally I can't look for /boost/foo//bar.
> Let me try again:
> - we check if there's /boost/foo/bar/Jamfile file
> - we check if there were some Jamfile which did
> project /boost/foo/bar ;
Wow. Well, I've lost track of the complete picture. As I said, I
need to see the syntax and semantics all written down together.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
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