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

[Peter Rosin]

Stefano Lattarini skrev 2012-01-19 14:55:
> * configure.ac: Look for "generic" C, C++ and Fortran compilers,
> with the aim of starting to use them in the testsuite (this will
> be done in future changes).  This is more tricky than it seems,
> since we don't want to abort the whole configure script even if
> no one of those compilers is available (after all, they're only
> needed by the testsuite, not to build automake), but currently
> autoconf doesn't offer an easy way to obtain this behaviour.
> We prefer non-GNU compilers to the GNU ones, to ensure better
> coverage "in the wild".
> ---
>  configure.ac |   82 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 81 insertions(+), 1 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index ddd6b2b..ea3671a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -38,8 +38,11 @@ AC_SUBST([am_AUTORECONF], ["${AUTORECONF-autoreconf}"])
>  AC_SUBST([am_AUTOHEADER], ["${AUTOHEADER-autoheader}"])
>  AC_SUBST([am_AUTOUPDATE], ["${AUTOUPDATE-autoupdate}"])
>  
> +dnl We call AC_PROG_CC in an unusual way, and only for use in our
> +dnl testsuite, so also use `no-dependencies' and `no-define' among
> +dnl the automake options to avoid bloating and potential problems.
>  AM_INIT_AUTOMAKE([1.10a dist-xz filename-length-max=99 color-tests
> -               parallel-tests silent-rules])
> +               parallel-tests silent-rules no-define no-dependencies])
>  
>  # The API version is the base version.  We must guarantee
>  # compatibility for all releases with the same API version.
> @@ -209,6 +212,83 @@ if test $am_cv_sh_errexit_works = no; then
>  fi
>  AC_SUBST([sh_errexit_works], [$am_cv_sh_errexit_works])
>  
> +
> +###########################################################################
> +
> +# Look for C, C++ and fortran compilers to be used in the testsuite.
> +
> +dnl We don't want to abort our configuration script if no C compiler is
> +dnl available, as such a compiler is only required to run part of the
> +dnl testsuite, not to build or install Automake.  Ditto for C++, Fortran
> +dnl and Fortran 77 compilers.  Unfortunately, autoconf does not offer an
> +dnl easy way to obtain this behaviour, so we'll need a few hacks.
> +
> +dnl We want the body of this macro to expand as a single shell statement,
> +dnl thus we wrap it into { ... } brackets.
> +AC_DEFUN([_AM_WRAP_MSG_ERROR], [ {
> +  AC_MSG_WARN([$1])
> +  am__failed=yes
> +  break
> +} ])
> +
> +AC_DEFUN([_AM_COMPILER_CAN_FAIL], [
> +  m4_pushdef([AC_MSG_FAILURE], m4_defn([_AM_WRAP_MSG_ERROR]))
> +  m4_pushdef([AC_MSG_ERROR],   m4_defn([_AM_WRAP_MSG_ERROR]))
> +  am__failed=no
> +  while :; do
> +     $1
> +     break
> +  done
> +  AS_IF([test $am__failed = yes], [$2])
> +  # We have to clear these cache variables, so that future checks on
> +  # compilers for different languages won't be confused.
> +  unset ac_cv_objext ac_cv_exeext
> +  # We also need to meddle with the autoconf internals to ensure that
> +  # checks to find object and executable extensions will be run anew.
> +  # FIXME: In the long run, the better thing to do would be to fix
> +  # FIXME: autoconf instead ...
> +  m4_undefine([m4_provide(_AC_COMPILER_OBJEXT)])
> +  m4_undefine([m4_provide(_AC_COMPILER_EXEEXT)])
> +  m4_popdef([AC_MSG_FAILURE])
> +  m4_popdef([AC_MSG_ERROR])
> +])
> +
> +# 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...

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

Cheers,
Peter