Re: [jamboost] toolset definition

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-12-16 08:15:28

David Abrahams wrote:

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

You are right.

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

The one in gcc-tools.jam -- not in V2 :-)

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

8-) That's certainly wrong. Did you find it in Perforce docs?

> 
> That can't be right, can it? Shouldn't it be
> 
> :E=value Use value instead if the variable is unset.

When I was hacking on expand.c half-an-year ago, that was the semantic.

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

Understood.

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

Agh.. if "IMPORT" imports actions too (which is the same, IIRC),
then there are not problems with inheriting actions.

>>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 still don't think that modules-as-classes give us much.
The problem is that it's not very selective: we'd inherit all
flags, rules and actions. If we just provide rules to import specific 
flags/rules/action, this would be enough.

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

Yes. The basic idea is:
1. The list of things that might be interesting when running tests is long.
Memory usage is one example. And we can't memory usage recording in
jam core.
2. There are some situation where I want to invoke an command via some helper
tool. For example, unit tests would typically be just run, e.g:

bin/gcc/debug/my_test

but sometimes I'd want to run it like this:

valgrind bin/gcc/debug/my_test

to catch uninitialized variables, etc.

So, we might add a new feature, "<launcher>". The value of this feature will
be added to the beginning of most command lines. This would allow to use
valgrind in the way I describe.

That done, we'd write a separate program, "test runner", which would lauch the
needed action, capture output, measure time, measure memory consumption and
write that information to an XML log.

Observe that regression testring already requires a separate utility that 
generates XML file. I'm suggesting to add more responsibilities to it.

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

+/- 0 Both names are equal to me.

> I'm open to thinking about
> this a little while.

The basics (as implemented now), are simple: "using" just
loads a module and forwards all arguments to it's "init"
rule.

What I'd really like is some kind of autodetection. I.e. if
gcc toolset if invoked without parameters, it GLOBS for gcc in
PATH. If nothing is found, it does not configure itself at all.
So, if user does not have gcc in PATH and have not configured it
explicitly, it won't be initialized and used for building.

What do you think?

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

OK. I'll add this to BB4 issue (which is assigned to you ;-) )

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

OK, maybe.

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

I cannot tell anything now, because I don't know what the problems were
and did not run in them yet.

- Volodya