[mpich-devel] overzealous F90/F90FLAGS error

[Dave Goodell (dgoodell)]

On Jan 13, 2015, at 10:53 AM, Jeff Hammond <jeff.science at gmail.com> wrote:

> On Tue, Jan 13, 2015 at 8:50 AM, Dave Goodell (dgoodell)
> <dgoodell at cisco.com> wrote:
>> 
>> Rather than remove this code altogether, it might be better to change the logic to complain more like this (untested):
>> 
>> if test -n "$F90" && test "x$F90" != "x$FC" ; then
>>    AC_MSG_ERROR([F90 set but not equal to FC.  This is almost certainly a mistake.  Either unset F90 or set F90="$FC"])
>> elif test -n "$F90FLAGS" && test "x$F90FLAGS" != "x$FCFLAGS" ; then
>>    AC_MSG_ERROR([F90FLAGS set but not equal to FCFLAGS.  This is almost certainly a mistake.  Either unset F90FLAGS or set F90FLAGS="$FCFLAGS"])
> 
> Except there are systems where FC=xlf2008_r F90=xlf90_r F77=xlf77_r is
> the right thing to do.  Thankfully, I no longer have to deal with such
> system, so I bring this up as an academic point.

I don't feel strongly about this, since I don't have to do much support of situations where users would make an F90/FC mistake.  But lots of past users of MPICH (from before the switch to using FC instead of F90) are likely to have scripts/documentation that uses F90 and is oblivious to the fact that it will be ignored.  So those users will have a pretty bad experience when their MPI installation uses a different Fortran compiler than they were expecting.  A plain warning from configure probably isn't enough for them to realize they made a mistake.

Also, as far as I recall, FC!=F90 is completely at odds with the current MPICH (and OMPI) build system(s).  I don't know whether those systems are correct or not, but it's how they are deliberately designed and implemented.

I've now used up all of my "care about what happens to Fortran" points for the month, so it's back to lurking for me...

-Dave