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'
> > 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,
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
I'm not sure either argument is a killer one, though.
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