From: David Abrahams (dave_at_[hidden])
Date: 2004-11-02 12:04:34
Vladimir Prus <ghost_at_[hidden]> writes:
> On Sunday 31 October 2004 23:36, David Abrahams wrote:
>> > Support for
>> > using /boost-stable : some-path ;
>> > would allow you to change the name the project is known elsewhere. I
>> > think that it's a good feature in itself, but not very important. Do
>> > you think otherwise?
>> I think it's moderately important for the sake of modularity.
>> I don't understand why that is "using" and not "project."
> It's being "using" historically. It's possible to use "project" for this case
> too, but given that usages for ordinary project:
> project boost : requirements <include>. ;
> and using of other project
> project boost : /home/ghost/Work/boost ;
> are pretty different, there's a question how to distinguish both usages, and
> whether one name for both usages is good. Here, I don't know whether
> uniformity or explicitness is more important.
project boost : . : requirements <include>. ;
Although "use-project" is fine.
>> > If we agree so far, then we need to decide on a method of avoiding
>> > specifying project ids completely.
>> > Basically, this could be either:
>> > 1. top-level rule which maps projects ids to locations
>> What does "top-level" mean?
> A rule which is defined in top-level Jamfile (in the same directory where
> project-root.jam is).
>> > 2. ability to prepend target id to the id declared in subproject, so that
>> > project python ;
>> > define project id boost/python.
>> > 3. Both options.
>> > In case of (2) there's a question if we allow non-global project ids. For
>> > example, can I use "top-level/p1/p2" in project at in top-level/p1/p3?
>> > Can I use "p1/p2" in the same place?
>> I don't see any reason to rule out any of the things you've
>> mentioned, but then I may not have a very complete picture of what
>> you're talking about.
I still think #3 is viable.
>> > I though it originates from you. Here a part of a post of yours:
>> >> Not if you had
>> >> use-project /boost : some-path ;
>> >> and in boost's Jamfile some mechanism like:
>> >> locate-subprojects libs/\\1/build \\1 ;
>> This is your "option 1" above, right?
Uh, no. When I wrote that, I assumed that locate-subprojects was
supplied by the build system, and... well I guess it *could* inject a
rule into the top-level Jamfile but... it isn't, on its face,
defining a rule.
-- 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