Re: toolset definition

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-12-16 10:38:57

David Abrahams wrote:

> So ask us some questions; we should try to clear that up.
> 
> 
>>>>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),
> 
> 
> The same as what?

"which is the case" was intended. Sorry for such an unintelligible typo.

>>>>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 don't think I agree. Take a look at intel and msvc for
> example. Almost everything is inherited. Asking for each one
> explicitly instead of saying "take everything but this and that" is
> going to be very cumbersome.

I understand. But, IMO, intoducing another high-level concept is not
needed. You can write some rule

toolset.inherit ( base : rules-to-exclude * : flags-to-exclude * )

or somethink along this lines. It's not much work to implement. On the
other hand, modules-as-classes is entirely new thing -- you'd have to design
them, document them and test them. I still believe simpler approach will work.

>>So, we might add a new feature, "<launcher>". 
> 
> 
> Note that I do something like that for the Python tests. I typically
> set -sPYTHON_LAUNCH="devenv /debugexe" in order to test under the VC7
> debugger.

Oh, great.

>>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.
> 
> 
> Fine with me.

OK, need to check if this is fine with Beman.

>>>>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.
> 
> 
> "using" still has too much resonance with something completely
> different in C++.

I'm pretty sure that resonanse with C++ is why you've picked that name
initialy ;-) Am I wrong?

OK, the point you made is good. I'm +0 for "configure".

> BTW, I really don't understand what you're up to in gcc.init:
> 
> # Initializes the gcc toolset
> # Each argument has the form:
> # version binary-name [path]
> # And specifies the name / path that should be used to invoke
> # the specified gcc version. The default version will be always called
> # with 'g++'.
> rule init ( a1 * : a2 * : a3 * )
> {
> if $(a1)
> {
> local version = $(a1[1]) ;
> local name = $(a1[2]) ;
> local path = $(a1[3]) ;
> 
> 
> 
> Why limit it to 3 installed versions? Why not, e.g.:
> 
> rule init( version ? name ? path ? : * )

It's just a first version. Yes, up to 9 version is better.

> What are the meanings of "name" and "path" above?

The meaning of name is simple --- the name used to invoke the compiler.
E.g 3.2 is called g++-3.2 on Debian. Path --- meant as gcc installation root,
but actually unused now.

> 
> I had always imagined we would probably make separate "using
> invocations" for each version of of the toolset we want to configure:
> 
> using gcc : 2.95 ;
> using gcc : 3.0.4 /usr/local/gcc-3.0.4 ;

That's ok, as far as I'm concerned. It's even somewhat better:
we don't have to dance around argument list of unknown size.

> GCC installations have a lot of variability: executables, libraries,
> and include files can all be installed in different locations, so
> eventually we'd want to accomodate that.

Yes. I guess that named parameters can help with it. E.g.

using gcc : 3.0.4
: binary /dir1
: headers /dir2
;

> 
> As a matter of fact, the "correct" way to deal with GCC is to locate
> the binary and parse the result of "gcc -v" as shown here:
> 
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/synopsis/Synopsis/Synopsis/Parser/C%2b%2b/emul.py?rev=HEAD&content-type=text/vnd.viewcvs-markup
> 
> (look for the find_compiler_info function)

I see. Not sure how can we do that. Maybe, via initial configuration step.
I.e. user will be asked to run "bjam configure" to detect installed toolsets.

>>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?
> 
> 
> I have a few doubts about the scenario above. How will the gcc
> toolset get invoked in the first place? It seems like an explicit
> request, so we should at least give the user an error if it can't be
> found in the path.

I believe that default site-config.jam should attempt to autodetect all
known toolsets. The syntax is not important, for example, something like

using gcc : autodetect ;

Such kind of invocation won't give errors if gcc is not found. Of course, explicit

using gcc : 3.2 /usr/local/gcc-3.2 ;

should give error if gcc is not found.

>>OK. I'll add this to BB4 issue (which is assigned to you ;-) )
> 
> 
> Funny, I don't see the information there. Oh, if I click "view as
> single screen, and wait... for it to refresh, it's at the bottom in
> the change history.
> 
> BTW, scarab, when it works, is really S L O W for me.

For me, it works not so slow (except for the cases when it drags its 200MB
tail across the swap space). Let's give it some more time.

(Actually, I'd really like to see some Python-based tracker, that I can
hack at if it misbehaves. Alas, Roundup does not seem feature-rich
and QMTrack development has stopped)

- Volodya