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

[Stefano Lattarini]

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

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

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

> [SNIP]

Thanks,
  Stefano