Re: [jamboost] Boost.Build V2, Jambase changes...

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-03-25 12:40:00

On 2002-03-25 at 12:06 PM, david.abrahams_at_[hidden] (David Abrahams) wrote:

>
>----- Original Message -----
>From: "Rene Rivera" <grafik666_at_[hidden]>
>
>
>> I've implemented part 1 of the new load behaviour.
>
>Hooray for Rene!!!
>
>> In particular the part that
>> involves changing the Jambase. I've comiited the changes to the
>Jambase in a
>> "boost_build_v2" branch. Part 1 is the loading of the build system
>only, not
>> the loading of the Jamfile, etc. For now the check for the name of the
>> executable succeeds when it has "bjam" in the name anywhere.
>
>Questions/nits:
>
>1. You're using tabs. The Perforce people have taken my suggestion it
>appears; they have the removal of all tabs from the source on their TODO
>list.

Ooops, forgot to replace those :-\

>2. I'm a little uncomfortable with glob-to-root used to search from a
>directory to the root, because it will keep searching upward even after
>the item is found. I know, I should not worry about this, but I keep
>thinking about network file systems, etc...

I'll try and change that, it was just easier that way. Question, since I'm
using Boost.Jam extensions in this would it then be OK to use a for loop
instead of the recursion?

>3. What's the point of the gTARGET_LOCATION() pseudo-function variable
>and the <bjam> grist? It's not obvious to me what you're trying to
>accomplish.
>
>I am trying to move away from pseudo-function variables, because all
>those parens get hard to read:
>
> $(foo(bar($(baz)))
>
>I vote for a simpler syntax, like gTARGET_LOCATION.$(file)

I was just following previous convention :-) But I can change it, now that
you've explained the reasons to stop using that. The grist is only so that the
use of the pseudo-function var doesn't interfere with onther uses of it. But
since we'll stop using them that way it won't be needed anymore.

The gTARGET_LOCATION is so that we can figure out file relative paths, this
might be better renamed to gFILE_LOCATION. I use this right now so that if the
"boost-build" rule gets called it can use the location of the boost-build.jam
file to reroot the relative path passed in to it.

>> I'll get to the changes for the rest of the loading soon... not today,
>but
>> sometime this week.
>>
>> Could someone check to see if what I did works correctly on Windows.
>> Particularly the path translation regarding "/".
>
>How can we check? Do you have a test somewhere?

Umm, good point :-O I'll put a test together!

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]