|
|
Boost-Build : |
From: David Abrahams (dave_at_[hidden])
Date: 2002-12-16 09:26:01
Vladimir Prus <ghost_at_[hidden]> writes:
> 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.
>>
>>>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 :-)
Oh, well that's my fault originally, but eventually it became Rene's
fault ;-)
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?
> then there are not problems with inheriting actions.
Yep.
>>>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.
>> 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.
Probably that would be inappropriate.
> 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.
Of course.
> 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.
> 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.
>>>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++.
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 ? : * )
What are the meanings of "name" and "path" above?
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 ;
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.
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:
(look for the find_compiler_info function)
>> 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 thoroughly agree.
> 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.
> 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.
>>> 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.
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk