Re: [jamboost] Python + bjam: some questions

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-03-09 04:54:06

Hi Pedro,

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

Did you build with --debug? Without it, it crashes for Linux too, and I'm yet 
to investigate why.

> > 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?)

Yes.

> 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)" ...')

The above makes sense for me.

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

I don't think it will give us anything....

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

... especially as generators will still get action id, not (toolset,action) 
pair. And making generator take (toolset,action) pair does not give any 
obvious benefits.

- Volodya