AX_MPI/ACX_MPI and packages using only the MPI compiler wrappers

[Ralf Wildenhues]

Hello Steven,

when using AX_MPI (formerly ACX_MPI (so search bots pick this up)) for
either some or all of the C, C++, and Fortran languages, the macro
documents a way to use it if all of the corresponding sources are to be
treated with the MPI compiler wrapper:

#   On success, it sets the MPICC, MPICXX, MPIF77, or MPIFC output variable
#   to the name of the MPI compiler, depending upon the current language.
#   (This may just be $CC/$CXX/$F77/$FC, but is more often something like
#   mpicc/mpiCC/mpif77/mpif90.) It also sets MPILIBS to any libraries that
#   are needed for linking MPI (e.g. -lmpi or -lfmpi, if a special
#   MPICC/MPICXX/MPIF77/MPIFC was not found).
#
#   If you want to compile everything with MPI, you should set:
#
#       CC="MPICC" #OR# CXX="MPICXX" #OR# F77="MPIF77" #OR# FC="MPIFC"

(sic typos  s/MPI/$&/g  by the way)

#       LIBS="$MPILIBS $LIBS"

My experience is that this is not quite sufficient, at least when
Automake and/or Libtool are added in the mix; it is unclear who to
attribute the problem to.

The gist of the problem is that with:

  AC_INIT([foo], [1.0])
  AM_INIT_AUTOMAKE([foreign])
  ACX_MPI
  CC=$MPICC


  # ...
  AC_CONFIG_FILES([Makefile])
  AC_OUTPUT

ACX_MPI first expands AC_PROG_CC which of course checks for the C
compiler etc.  But also, automake attaches dependency tracking checking
to AC_PROG_CC.  This means, all those tests done right after AC_PROG_CC
are done with $CC and not with $MPICC.  So, when a user does

  ./configure MPICC=/super/duper/mpicc

and that driver doesn't use, say, the first gcc found in $PATH, all
those test results are problematic.

I've been using something like this as a workaround:

  # Do not even look for a non-MPI C compiler if MPICC is set.
  if test -z "$CC" && test -n "$MPICC"; then
    CC=$MPICC
  fi
  AX_MPI
  CC=$MPICC
  LIBS="$MPILIBS $LIBS"

under the assumption that if the user passes both variable, she knows
what she's doing, and when neither are passed, well then, let's hope
gcc/cc and mpicc will somehow be similar.

I'm not sure how a better solution would look like, given that your
AC_CHECK_PROGS instances for MPICC et al fall back on $CC in the
not-found case.  Without that, and given some argument to the ACX_MPI
macro could make it safely override before expanding AC_PROG_CC.

Suggested patch attached (in format suitable for piping to 'git am -3').

Thanks,
Ralf

0001-Fix-recommendation-for-compiling-everything-with-MPI.patch
Description: Text document