Re: [jamboost] Perforce Jam incompatibility

From: David Abrahams (dave_at_[hidden])
Date: 2002-11-18 10:35:31

Rene Rivera <grafik666_at_[hidden]> writes:

> [2002-11-15] David Abrahams wrote:
>
>>
>>I was just looking over Rene's new document at
>>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/tools/build/jam_src/readme.html,
>>which says,
>>
>> "It contains significant improvements made to facilitate its use in
>> the Boost Build System, but should be backward compatible with
>> Perforce Jam"
>>
>>Well, we have one known backwards(?)-incompatibility:
>>
>>When Perforce introduced rule indirection, they did it a bit
>>differently than we did:
>>
>> x = a b ;
>> y = [ $(x) c d ] ;
>>
>>In Boost.Jam, this is equivalent to:
>>
>> y = [ a b c d ] ;
>
> Logical.
>
>>In Perforce Jam, this is equivalent to:
>>
>> a c d ;
>> y = [ b c d ] ;
>
> Yikes, how unintuitive.

Heh, it's perfectly intuitive to Christopher Seiwald ;-)

>>Either behavior can be built in terms of the other, but I thought
>>the Boost.Jam behavior was more-useful, and we were there first, so
>>I didn't change it when Perforce added rule indirection. I don't
>>know if that was a bad choice. However, we ought to decide whether
>>to keep that difference, and if so, how to document it.
>
> Is there any way to support both? 

I'm sure there is, but is it a good idea?

> That is can we decide at runtime which one to use, for instance by
> using the bjam vs jam invocation? 

That makes my hair stand on end.

> Perhaps a builtin, like Vladimir did with the UPDATE to make up for
> removing the command args functionality.
>
> I'm curious because I think having that compatability with Jam/MR
> might be important when we put back in the 2.4 Jambase.

I can understand that sentiment. Maybe it's better to have it than to
not have it. We ought to consider (briefly) how costly it would be to
adopt an "eval" rule which handles argument binding for rule
indirection. Of course, if we do that, we can also implement _1, _2,
... placeholders for fully flexible bind functionality

I _think_ I'm just kidding about that last part ;-)

-- 
David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution