From: David Abrahams (dave_at_[hidden])
Date: 2003-12-15 12:18:13
Vladimir Prus <ghost_at_[hidden]> writes:
> David Abrahams wrote:
>> >> The problem with builtins is that they are declared and executed in
>> >> global module. This means that if rule accesses module variables, or if
>> >> rule is a class method, we're in trouble, since those variables can't be
>> >> accessed, at least cleanly.
>> > Isn't that what the "localize" parameter to IMPORT is for?
>> Volodya, I don't mean to press you, but I'm afraid that large and
>> unneccessary changes could get made if you don't consider this
> Sure. I did asked about the proposal precisely to make sure this is not a
> mistake. I was not able to reply on Friday because we had yet another holiday
> here in Russia.
> Now about 'localize' -- I did not consider it at the moment. IIUC, with
> 'localize', the whole thing will work like:
> 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
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
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
-- 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