toolset definition

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-12-15 03:31:04

David Abrahams wrote:

> I think I can help with MSVC. I think a few other people have
> contributed to that toolset definition.
>
> BTW, I've been sitting on some thoughts about how to do toolsets for
> some time, and I'd like to make sure they are considered:
>
> I think if every toolset ends up looking like the GCC toolset does
> today, people will find it extremely difficult to add new ones. We
> need to work on the interface for toolset definition.

It's true. However, much of the gcc-tools.jam complexity is due to having
lots of cases for different OSes. If we introduce <os> feature this would
be simplified. In addition, we can split toolset defininition into one main 
file and several OS-specific.

The second source of complexity is the "Link-action" which I can't understand 
at all.

> * Toolsets should be like single-module classes. Maybe some new
> infrastructure is needed to support Java-style module files which
> define a class and nothing else.

This might be good or bad. Can you tell what precisely you have in mind?
The gcc.jam for V2 really has no rules, only actions and flags settings. Is it 
possible to inherit actions? And while some flags inheritace is needed, I'm 
not sure making classes of modules is much help here.

>
> * I believe that some core actions can be re-used for many toolsets.
> This may be especially important for action modifiers, e.g. suffixes
> which capture the output of the action.

1. By "suffixes" you certainly mean testing support. I really don't think that
current testing system should be carried over to V2, but it's not relevant to
the current discussion. Just wanted to point that a discussion about testing
will be needed.

2. We certainly need some reuse. E.g. things like <define> are handled in the
same way in all toolsets. These are the things that exists in toolset 
definition module:

1. Initialization code ("init" rule). This is called via "using" 
(see the architecture document) and set up toolset. Not sure we
can archive much reuse.
2. Toolset flags. This is the most common thing. Two possibilities for reuse 
are:
- some common definitions, like <cxxflags>
It's possible to reuse them explicitly, for example

toolset.inherit-flags common.compile : gcc.compile ;

would copy all flags for common.compile to flags for
gcc.compile.

- extending a toolset. I'm not sure we need this. Maybe, with 
toolset-version feature, only one module can handle all
gcc variants. If we need it, it's where modules-as-classes idea
looks relevant. OTOH, I think that some less general solution
could work. E.g.

toolset.inherit gcc ;

can bring all rules from gcc module into the current module and
also bring all flags. 

- Volodya