Re: AC_PROG_F77 thinks my compiler is g77 (its not!)

[Paul Martinolich]

Akim Demaille wrote:
> but for Fortran 77, $1 was ignored :(
> 
> # AC_LANG_PROGRAM(Fortran 77)([PROLOGUE], [BODY])
> # -----------------------------------------------
> # Yes, we discard the PROLOGUE.
> m4_define([AC_LANG_PROGRAM(Fortran 77)],
> [      program main
> $2
>       end])
> So, what should it be?
> 
> [      program main
> $1
> $2
>       end]
> 
> or
> 
> [$1
>       program main
> $2
>       end]
> 
> ?

I think the second model would work, but the default is that $1 should
be empty.  Perhaps the order in the call is backwards.  For C, it is
standard practice to have pre-processing statements in $1 and the body
of the code in $2.  In Fortran, unless the body needs a special data
block or function, there is no standard prologue.  That is, $1 is almost
always empty.

# AC_LANG_PROGRAM(Fortran 77)([BODY], [PROLOGUE])         <--- note
# -----------------------------------------------
# Yes, we discard the PROLOGUE.
m4_define([AC_LANG_PROGRAM(Fortran 77)],
[$2   
       program main
$1
       end])

This breaks the convention used for C and C++, however.

The main problem is the use of C pre-processing statements in Fortran.
The _language_ does not specify these types of statements.  The vendors
of Fortran compilers decided to allow their compilers to run the Fortran
source through cpp.  But each took different paths as I outlined in my
previous post.

The _AC_COMPILER_GNU macro uses the cpp statements:

#if __GNU__
#endif

to determine if the compile is a GNU compiler.  In strict Fortran,
these statments are illegal!  Unfortunately, I don't believe there
is a way (in strict Fortran) to determine those characteristics of
the compiler.

Automake treats the Fortran compiler as two different compilers, like
C and C++ are different compilers (even though C++ is (was) a superset
of C).  From automake:

&register_language ('f77', 'linker=F77LINK', 'flags=FFLAGS',
                    'compile=$(F77) $(AM_FFLAGS) $(FFLAGS)',
                    'compiler-name=F77COMPILE',
                    'output-arg=-c -o $@',
                    'f', 'for', 'f90');
&register_language ('ppf77', 'linker=F77LINK', 'flags=FFLAGS',
                    'compile=$(F77) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS)
$(CPPFLAGS) $(AM_FFLAGS) $(FFLAGS)',
                    'compiler-name=PPF77COMPILE',
                    'output-arg=-c -o $@',
                    'F');

One Fortran compiler is strict (that is, no pre-processor statements)
and the other is a so-called "pre-processing Fortran compiler".

Perhaps, a solution is language specific _AC_COMPILER_GNU macros.
Like _AC_COMPILER_GNU(C), _AC_COMPILER_GNU(C++), _AC_COMILER_GNU(PPF77),
etc.  The macro _AC_COMPILER_GNU(Fortran 77) would have to always return
'no' because it can't determine if it is a GNU compiler using strict
Fortran source.

To me, the best solution would be to replace the generic
_AC_COMPILER_GNU
macro from AC_PROG_F77 with the 2.14 AC_PROG_F77_GNU macro.  The only
problem
with that macro maybe how different Fortran compilers handle the .fpp
extension.  The SGI, ABSOFT, and GNU compilers I work with all handle it
fine.

-- 
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Paul Martinolich/Software Engr.   e-mail:
address@hidden
Neptune Sciences, Inc.            voice: (228) 688-5280
NRL Remote Sensing/Ocean Color    http://www7240.nrlssc.navy.mil/ocolor/