From: David Abrahams (dave_at_[hidden])
Date: 2003-12-17 15:01:00
Vladimir Prus <ghost_at_[hidden]> writes:
> David Abrahams wrote:
>> > 1. You declare builtin called 'set.difference'.
>> You could call it anything.
>> > 2. Insides the 'set' module, you put
>> > IMPORT : set.difference : $(_name) : difference : localize ;
>> > EXPORT set : difference ;
>> > 3. After 'set.jam' is read, the 'difference' rule is exported into global
>> > scope, and now 'set.difference' behaves as rule declared in 'set', but is
>> > in fact implemented in 'C'
>> > The good thing about the proposal is that it does not require a new
>> > builtin.
>> You mean _my_ proposal?
>> > The only thing I don't like is cluttering the global namespace.
>> > After all, the implementation -- the .c files declaring new rules -- is
>> > better live in separate files in 'modules' directory, as builtins.c is
>> > large enough already. It's nicer if namespaces follow that layout, though
>> > it's not critical.
>> It should be very easy to get builtin rule declarations to go into a
>> specific module. You could even do it by searching for "." in the
> Interesting. In this case one would not need the IMPORT/EXPORT stuff at all,
Well, not for this case.
> But then the only difference with my proposal is that builtin is added
> to module immediately, whereas for my approach they are hidden unless you
> call 'NATIVE_RULE'. This allows to leave the original definition of the rule
> there and just add NATIVE_RULE call after it -- i.e. you can easily switch
> between C and jam implementation.
Why does it matter which one replaces the other?
You can always replace the C implementation with the jam one later.
-- Dave Abrahams Boost Consulting 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