Re: [jamboost] Re: Native rules proposal

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-12-16 02:45:26

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'
>
> Yep.
>
> > The good thing about the proposal is that it does not require a new
> > builtin.
>
> You mean _my_ proposal?

Yes.

> > 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
> name.

Interesting. In this case one would not need the IMPORT/EXPORT stuff at all, 
right? 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. 

This is usefull for trying both alternatives and understanding how much 
speedup we get. Or we might even make NATIVE_RULE do nothing when
native rule is not available, which would Boost.Build work with several bjam 
version, not necessary the latest. And finally, if you introduce builtin and 
remove jam version of the rule, you don't have a place where to put 
docstring.

I'm not sure either argument is a killer one, though.

- Volodya