Re: [jamboost] toolset definition

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-15 12:41:10

Vladimir Prus <ghost_at_[hidden]> writes:

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

I think we need to be careful with that one, since there might be
distinct host and target os.

> In addition, we can split toolset defininition into one main 
> file and several OS-specific.

Yep.

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

What don't you understand? You wrote it, didn't you?

Hmm, I notice the use of :E in there, which I've never used... I
looked it up, and it said:

:E=value Assign value to the variable if it is unset. 

That can't be right, can it? Shouldn't it be

:E=value Use value instead if the variable is unset.
??

I'm sure that's not the part you don't understand, though...

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

Not precisely.

I think the basic "extends toolset" idea from v1 should be preserved.
The general idea was that there was a base msvc toolset from which
various other toolsets were derived.

However, the way the v1 system works, via inclusion, is way too
capricious. It's very difficult to know how/when/where to override
something. I'd like to replace that with a system that's more
predictable, and I'd like to refactor more of the toolset logic into
common base toolsets.

> The gcc.jam for V2 really has no rules, only actions and flags
> settings. Is it possible to inherit actions? 

We can certainly make it possible. There's no a priori reason that
every toolset needs to have its own "link" action.

> And while some flags inheritace is needed, I'm not sure making
> classes of modules is much help here.

Maybe my clarifications above help (I hope?)

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

That's one thing I had in mind. I also thought of adding timing or
other post-processing.

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

Well of course it would have to be different in some ways. However, I
think the sane-testing version of testing.jam is pretty good. Did you
have something radically different in mind?
>
> 2. We certainly need some reuse. E.g. things like <define> are handled in the
> same way in all toolsets. 

Yep.

> These are the things that exists in toolset definition module:
>
> 1. Initialization code ("init" rule). This is called via "using" 
> (see the architecture document) 

Thanks for the reminder! Probably a name change is in order, since I
had to look it up. Maybe 'configure'? I'm open to thinking about
this a little while.

> and set up toolset. Not sure we can archive much reuse.

Probably not.

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

OK, that's a pretty straightforward and selective approach.

> - extending a toolset. I'm not sure we need this. Maybe, with 
> toolset-version feature, only one module can handle all
> gcc variants. 

I don't know, think of MSVC/Intel/ComeauWin32...

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

Maybe most of the capriciousness of the v1 approach would go away if
we are disciplined about handling the toolset's configuration (via
init). That seems to have been the biggest problem with the v1
system. However, there were also issues related to propagating the
paths to the compiler's runtime libraries around, so that they'd be
added to the [LD_LIBRARY_]PATH when tests were run, etc.

-- 
David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution