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

[Peter Rosin]

Stefano Lattarini skrev 2012-01-20 15:02:
> Hi Peter.
> 
> On 01/20/2012 12:56 PM, Peter Rosin wrote:
>> Stefano Lattarini skrev 2012-01-19 14:55:
>>
>> [MEGA-SNIP]
>>
>>> +# Prefer generic compilers to GNU ones when possible.  This will ensure
>>> +# more testsuite coverage "in the wild".
>>> +# FIXME: maybe we should a more comprehensive list too look for more
>>> +# FIXME: "exotic" compilers?  And what about looking also for the MSVC
>>> +# FIXME: compiler on Cygwin/MinGW systems?
>>> +_AM_COMPILER_CAN_FAIL([AC_PROG_CC([cc gcc])], [CC=false])
>>
>> Looking for MSVC on Cygwin is a definite no, IMHO.  MSVC can't produce
>> Cygwin programs (I have never heard of it anyway, maybe with -nodefaultlib
>> and adding a bunch of low level cygwin stuff instead, but I highly doubt
>> it will fly), so it can only be viewed as a cross compiler in that
>> setting. IOW, the same as looking for it on Linux with Wine/binfmt-misc...
>> BTW, that's a good starting point for how Cygwin should be viewed when it
>> comes to build systems; as Linux with Wine and binfmt-misc set up to
>> handle PE stuff.
>>
>> MinGW is another matter...
>>
> Thanks for the detailed information.  I'll adjust the FIXME comment
> accordingly.
> 
>>> +
>>> +# 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.

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.

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

>> But I usually don't
>> source my script that adds MSVC to PATH and sets up various other bits
>> needed in the environment when in Cygwin, so cl.exe isn't normally on my
>> PATH so it wouldn't be a problem *for me*.  But I think there is an option
>> to add MSVC to the "global" environment though, and if that has been done,
>> it might not be so easy to avoid finding MSVC from Cygwin.
>>
> So the hack I have proposed above might be necessary after all.  Damn.
> 
> I will await confirmation from you that I have inderstood the situation
> correctly, before proceeding to write a patch.

Ok.

Cheers,
Peter