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
