On 05/30/2013 08:20 AM, Peter Rosin wrote:
> On 2013-05-30 00:39, Stefano Lattarini wrote:
>> On 05/30/2013 12:14 AM, Peter Rosin wrote:
>>> Hi!
>>>
>>> I just tried the testsuite on maint with MSYS/MSVC and I have one
>>> failure, namely in silent-many-languages.sh. The reason it fails is
>>> that while I have specified MSVC as the C and C++ compiler, I didn't
>>> bother to say that I wasn't interested in fortran. The many-lang
>>> test then mixes the output from the GCC fortran compiler with the
>>> output from MSVC, which is perhaps not very wise but appears to work
>>> for the trivial code in the testcase once you fix the automake
>>> machinery to allow it.
>>>
>>> The problem with the automake machinery in this case is that GCC
>>> uses foo.o, while MSVC uses foo.obj, and it so happens that GCC
>>> "wins" and OBJEXT is set to "o". This, coupled with the fact that
>>> automake tries not to use the -o option unless it's really needed
>>> causes make rules to be created w/o -o, but MSVC will then create
>>> foo.obj, which fails badly during linking when automake expects
>>> foo.$OBJEXT, i.e. foo.o.
>>>
>>> So, since the maint branch already assumes that -c -o works, how
>>> about the below change? It makes the test PASS for me, and I see
>>> no regression in any other test (but I have a lot of SKIPs, so
>>> I'm not really confident that the change will not cause some
>>> spurious FAILs in any of those).
>>>
>>> The concept seems sound to me, but it's perhaps too dangerous?
>>>
>>> Cheers,
>>> Peter
>>>
>>> diff --git a/bin/automake.in b/bin/automake.in
>>> index 24ff2a6..40b3181 100644
>>> --- a/bin/automake.in
>>> +++ b/bin/automake.in
>>> @@ -632,6 +632,7 @@ register_language ('name' => 'c',
>>> 'linker' => 'LINK',
>>> 'link' => '$(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS)
>>> $(LDF
>>> 'compile_flag' => '-c',
>>> + 'output_flag' => '-o',
>>> 'libtool_tag' => 'CC',
>>> 'extensions' => ['.c']);
>>>
>>> @@ -1313,14 +1314,6 @@ sub handle_languages ()
>>> if (((! option 'no-dependencies') && $lang->autodep ne 'no')
>>> || defined $lang->compile)
>>> {
>>> - # Some C compilers don't support -c -o. Use it only if really
>>> - # needed.
>>> - my $output_flag = $lang->output_flag || '';
>>> - $output_flag = '-o'
>>> - if (! $output_flag
>>> - && $lang->name eq 'c'
>>> - && option 'subdir-objects');
>>> -
>>> # Compute a possible derived extension.
>>> # This is not used by depend2.am.
>>> my $der_ext = ($lang->output_extensions->($ext))[0];
>>> @@ -1364,7 +1357,7 @@ sub handle_languages ()
>>>
>>> COMPILE => '$(' . $lang->compiler . ')',
>>> LTCOMPILE => '$(LT' . $lang->compiler . ')',
>>> - -o => $output_flag,
>>> + -o => $lang->output_flag,
>>> SUBDIROBJ => !! option 'subdir-objects');
>>> }
>>>
>>>
>> I think we already have something similar in master, in fact. Not sure
>> why I didn't apply that directly to maint, since all the changes necessary
>> for such a simplification are in maint as well. Perhaps because I did
>> this simplification in a middle of another master-based patch series, so
>> that it didn't apply cleanly to maint? Probably so.
>>
>> In short, I agree this change goes in the right direction. Thank you.
>> Extra kudos if you can prepare a patch with the complete explanation,
>> and maybe even a reference to the similar change already landed in
>> master. I will give a fresh round of tests on Fedora, Debian, BSD
>> and Solaris tomorrow.
>
> I'm not sure we should even hint at any support mixing MSVC and GCC,
> which would be implied if we did this change in order to fix the
> testsuite failure. I believe this change needs to stand by itself,
> because the testsuite failure is not an important case, it was just
> how I got to look at the code and what drove the .o vs .obj
> confusion, that's all. That said, I suppose I can mention it with
> a fair warning that nobody recommends mixing toolchains.
>
> The commit you're referring to is 020fb48db730a5 "subdir-objects:
> enable unconditionally", right?
>
Actually no, it was one if its follow-ups. Let me dig for it ...
Here: v1.13.1d-217-g7299c4d "depend: assume we can always pass '-o'
to the C compiler".
> (I'm on master now, so I'll write up a suggestion for the commit
> message later, when I'm done with bug#14499 and bug#14501)
>
OK, thanks.
Regards,
Stefano
