octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Avoiding g77


From: Rik
Subject: Re: Avoiding g77
Date: Thu, 27 Nov 2014 19:01:52 -0800

On 11/26/2014 09:06 AM, John W. Eaton wrote:
> On 11/26/2014 11:41 AM, Daniel J Sebald wrote:
>> On 11/26/2014 10:03 AM, Mike Miller wrote:
>>> On Tue, Nov 25, 2014 at 23:08:41 -0800, Rik wrote:
>>>> I think the best solution may be an explicit check for g77 and
>>>> issuing an
>>>> error message if it is selected.
>>>
>>> How about a version check instead? The g77 program only exists for gcc
>>> <  4. Add a check for GFORTRAN_VERSION, and if it is a GNU compiler and
>>> the version is less than 4, issue an error? That seems more robust
>>> than checking for the name being g77.
>>>
>>>> I was concerned about the brittleness of the sed solution, and
>>>> accidentally
>>>> found that it is not robust.  The prologue which replaces g77 with
>>>> gfortran
>>>> is run at the end of the bootstrap sequence.  However, if the time
>>>> stamp on
>>>> configure.ac is modified, then the existing Makefiles take care of
>>>> re-running aclocal, automake, and autoconf.  They do not run any
>>>> bootstrap
>>>> epilogue so the effect is to re-instate the default AC_PROG_F77 macro
>>>> from
>>>> autoconf which has g77 listed first.  If you are a developer,
>>>> adjusting the
>>>> time stamp can happen whenever you do an 'hg update' where there has
>>>> been a
>>>> change in configure.ac.  This is important because 'make dist'
>>>> packages up
>>>> the configure script that it finds into the tarball.  If one isn't
>>>> aware of
>>>> this oddity then the wrong configure script can be exported to
>>>> everyone.  I
>>>> checked the tarballs for versions 3.8.2, 3.8.1, 3.8.0, and 3.6.4 and
>>>> they,
>>>> at least, are clean.
>>>
>>> Agreed, that could happen. So are you proposing to delete
>>> bootstrap_epilogue, and we say that an error check at configure-time
>>> for g77 (or less than version 4) is enough to avoid the original
>>> problem this was meant to solve? That sounds like a decent compromise
>>> to me, especially now that systems with g77 are increasingly rare.
>>
>> I'm fine with the change as well.  The use of the epilogue isn't such a
>> problem, as much as the sed modifying and overwriting the file "configure".
>>
>> One small variation on Rik's solution is the following:  If gfortran is
>> our preferred compiler, we could first check for gfortran above all
>> others using legal AC syntax, i.e.,
>>
>> AC_PROG_F77([gfortran])
>> if F77 is not defined
>>    AC_PROG_F77
>>    if F77 is g77
>>      error message "g77 is not supported, please choose another FORTRAN
>> 77 compiler via environment variable F77
>>    fi
>> fi
>
> This seems like a reasonable solution to me.  I'm not as concerned about
> g77 being installed with some other name, but if there is a way to
> identify g77 without just looking at the name of the program that would
> be fine with me too.
>
> I agree that the problem I was trying to solve is probably not much of a
> problem now, though it certainly was for a while, when people had old
> versions of g77 installed that were incompatible with their version of GCC.
>

I think this is mostly a non-issue now.  g77 was back in the 3.X series of
gcc and recent new version tests in Octave's configure.ac require at least
version 4.1.  I have checked in a change that removes the
bootstrap_epilogue and makes gfortran the preferred compiler.  The autoconf
code is now

## Prefer gfortran, but the user's F77 environment variable will override.
AC_PROG_F77([gfortran])
if test -z "$F77"; then
  ## No gfortran found, search for any other installed compiler.
  AC_PROG_F77
fi
if test "$F77" = g77; then
  AC_MSG_ERROR([g77 is not a supported Fortran compiler.  Select another
compiler by setting the environment variable F77 and re-running configure.])
fi

--Rik



reply via email to

[Prev in Thread] Current Thread [Next in Thread]