Re: [PATCH 1/6] configure: search generic compilers for use in the tests

[Peter Rosin]

Stefano Lattarini skrev 2012-01-20 19:14:
> On 01/20/2012 06:14 PM, Peter Rosin wrote:
>>>>> +
>>>>> +# The list of C++ compilers here has been copied, pasted and edited
>>>>> +# from `lib/autoconf/c.m4:AC_PROG_CXX' in the Autoconf distribution.
>>>>> +# Keep it in sync, or better again, find out a way to avoid this code
>>>>> +# duplication.
>>>>> +_AM_COMPILER_CAN_FAIL([AC_PROG_CXX(dnl
>>>>> +  [aCC CC cl.exe FCC KCC RCC xlC_r xlC c++ cxx cc++ gpp g++])],
>>>>> +  [CXX=false])
>>>>
>>>> I suppose it can be a problem that cl.exe is before g++ on Cygwin or Linux
>>>> with Wine/binfmt-misc and if MSVC is installed (and visible), when cl.exe
>>>> is best viewed as a cross compiler in those cases.
>>>>
>>> Are you afraid that configure will, in such a setup, automatically (and
>>> erroneously) determine that we are *not* cross compiling, while in fact
>>> we are?  If yes, I agree that would be problematic.  Maybe we could (in
>>> a follow-up patch) avoid looking for cl.exe if we determine the current
>>> build system is Cygwin?  Ugly, but easy to do (and also correct, I hope).
>>
>> No, that's not what I'm afraid of.  I'm afraid, when $host == $build, that
>> configure will think that cl.exe is a native compiler.  I mean, it's not
>> as if it's named i686-pc-mingw32-cl.exe just because you are in a Cygwin
>> shell, and when it is on PATH in a Cygwin setting it will produce
>> executables that run, and I fear that configure will think the compiler
>> is fine.
>>
> Which is true for our purposes, no?  I mean, the automake testsuite makes
> (or at least should make) only two general assumptions about the compilers
> it uses:
> 
>   - they can build executables
>   - if $(build_alias) == $(host_alias), they can run those executables
> 
> So the scenario you're depicting shouldn't be problematic (either that
> or, more likely, I am still misunderstanding something).

It might be true that the testsuite is not making other assumptions (that
happen to not hold).  I don't know.  But such assumptions very easily
creep in even if they don't exist today, and I will probably be the one
chasing the "problems".  And what is the point in going after the complete
non-issues it likely will be when using MSVC from non-MSYS?

E.g. if a testcase starts to assume that you can feed absolute paths to
the compiler, and it doesn't use AM_PROG_CC_C_O.  Is that really useful
to catch?  That was just an example with an easy fix, but the fix isn't
so easy with fd 9 in that other bug (#10466) which means that we will
probably have to live with some FAILs.  And every FAIL is going to cost
time in the long run.  My time...

>> So, I'm not afraid that the cross-or-not heuristic will come up with the
>> wrong answer.  I'm afraid that CC will point to a cross compiler in a
>> native build, which would be surprising when gcc is on PATH, and probably
>> even before cl.
>>
> But consider that the compilers are only needed for use in the automake
> testsuite , so it's not a problem if an "inferior"/"unusual" compiler gets
> selected by configure; in fact, it's a *feature*, since the whole point
> of this patch series is to make it easier and more automatic to run the
> testsuite with unusual, vendor-specific, or fringe compilers, to improve
> coverage "of the wild".  But see below.
> 
>> I believe the correct thing to do is to only look for cl when $host is the
>> system cl produces code for.  But that's very difficult, as there are cl:s
>> that produce code for other arches (x64, Itanium).  But since I think it's
>> too hard to do this right, I don't think we should even try.  But I also
>> think that we should only look for cl if we have failed to find gcc/g++,
>>
> Oh no -- I explicitly want to *prefer* cl.exe over gcc/g++!  If you
> think this could be problematic on Cygwin, then we might explicitly
> avoid considering cl.exe on that particular system, to avoid weird
> or spurious failures.
> 
> *OR* it occurs to me that we could simply take a step back, and avoid all
> the potential problems you are foreboding simply by avoiding looking for
> cl.exe *at all*.  Instead, we will add proper advice in 'tests/README'
> explaining how to run the testsuite on MinGW with MSVC as C/C++ compiler.
> This way, we can assume the user will be knowledgeable and motivated
> enough to avoid common misconfigurations; more importantly, we'll avoid
> the risk of automatically producing such misconfigurations ourselves.
> 
> WDYT?

I think it would perhaps be best if MSVC is only considered if fed
explicitly.  The number of users running the Automake testsuite on
Cygwin or MSYS/MinGW is vanishingly small (that's my guess anyway),
and the support for gcc has to have higher priority than for MSVC.
Given the number of problems that tend to crop up when running the
testsuite on fringe systems such as MSYS/MinGW, due to various corner
cases, it would probably just be seen as an annoyance if MSVC is also
thrown into the mix.

Anyway, if you still want to keep it, I think that it should only
be considered when the host is MinGW.  I.e., don't stop at excluding
it on Cygwin, instead go all the way and exclude it everywhere except
on MinGW.

>> that way we avoid that particular can of worms in the vast majority of
>> cases.
>>
>> Perhaps it's as simple as moving cl.exe over to the end?
>>
> That would basically defy the purpose of having it there.

Right. :-)

Cheers,
Peter