Re: [jamboost] Python + bjam: some questions

From: Pedro Ferreira (pedro.ferreira_at_[hidden])
Date: 2005-03-07 09:33:31

Hi Volodya,

On 5 Mar 2005, at 08:29, Vladimir Prus wrote:

>>> but "import bjam" means the module is only usable with bjam. Which
>>> gives two
>>> questions:
>>>
>>> 1. I've added Jamfile loading to the ProjectRegistry code. Do you 
>>> find
>>> it
>>> desirable to split the logic into a separate module, so that
>>> project.py can
>>> be used without bjam? This should be easy -- just moving one class 
>>> from
>>> project.py to another module, but maybe I worry too much?
>>
>> If it isn't asking too much, I'd rather have it separate, please: I'd
>> really like to be able to create projects just using python.
>
> No problem, done. I have committed by modifications. Please update and 
> take a
> look at python/README.txt for instructions. Note that I've tested on 
> Linux,
> and more work is needed to enable bjam's Python support on Windows.
>
> I'd appreciate if you try the changes.

It crashes on Darwin. I'll check this and try it on Windows as soon as 
I can.

> I think we need some discussion here. Now the action name stored in 
> the Action
> class:
> - must be callable
> - must provide __name__ attribute which is then passed to build engine
>
> For the make rule, the action is specified in Jamfile, and the above 
> is not
> very convenient. I don't think defining a function with the same name 
> as
> action name is nice, so I've created BjamActionWrapper class which is
> callable and which __name__ attribute is equal to the action name (see 
> the
> action.py file). And since it's callable, I've modified the __call__ 
> method
> to call bjam and set up the actions.
>
> What I'm driving at is that if action is callable, then we don't need 
> do
> handle the name, the call can do anything. If we use only the name, 
> then why
> require that action is callable? Say the __call__ method can both set 
> up
> target variables and then call bjam. What would be the role of
> BjamBuildSystem is not clear. Maybe it should be just a factory for
> appropriate actions? I really don't know the right approach yet.

You stumbled on the area I've been having more problems getting it 
right lately and was planning to bring it up on the list today.
The main problem is to deal with inheritance of rules and generators.

Context:
In BBV2, you create generators and assign them an id. Then, if the 
generator is selected, the rule with the same name as the id is called 
and a similarly named update action is set up.
If you extend one toolset from another one, you inherit generators, 
rules and actions and then selectively override them.
In BBv2, the part of an id up to the first dot is treated as a toolset 
name, the rest being the name of the specific action. So, when you 
inherit from one toolset, the first part of each id is modified to have 
the name of the new toolset.

(Is this correct?)

Proposal:

- Extend the action registry to allow one to register rules and actions 
and to associate them with an id.
E.g.,

action.register ('gcc.compile.c++', compile_cpp_call_it_anything, 
'"$(CONFIG_COMMAND)" $(LANG) -Wall ...')

Implement inheritance of rules and actions:

action.inherit_rules ('darwin', 'gcc')

And overriding:

# Override just the action but keep the rule
action.override ('darwin.compile.c++', None, ''$(CONFIG_COMMAND) 
$(ST_OPTIONS) -L"$(LINKPATH)" ...')

If this is ok, what about explicitly separate the toolset from the rule?

action.register (toolset, rule_name, rule, action_text)

This would make it clear the meaning of the text up to the first dot. 
The rule_name is still hierarchical (e.g. 'compile.c++' inherits all 
flags from 'compile') but the toolsets are clearly separate.

- Change back the generator constructor to receive an id and not the 
rule itself. Then, when the rule needs to be called, ask it to the 
action registry.

Comments please!

Pedro