From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-12-15 01:30:16
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'.
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.
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
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