Boost logo

Boost-Build :

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

Dave Abrahams
Boost Consulting

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at