Re: How to create tests for FC?

[Steven G. Johnson]

> > Your
> > tests should also normally use AC_COMPILE_IFELSE which uses the current
> > extension and flags (if any).
>
> Not so good.  Currently, libtool.m4 uses $ac_compile but modifies it so
> that the compiler flag we are currently testing comes right after the
> last *FLAGS variable, if any, or before the first word that matches
> `conftest.', or at the end.  This is (I believe) so that it works with
> several Autoconf versions, programming languages, compilers, and I feel
> quite uneasy changing it for the established languages, as this code has
> evolved a long time.  Now I guess that macro breaks $FCFLAGS_$SRCEXT use
> which needs to come right before the source file name.  :(

I don't think you have any choice here.  For the Intel compiler, the -Tf 
flag has to come immediately before the source file.  So, you have to 
modify your behavior, at least for Fortran.

I would suggest that you let autoconf decide what is the right place to 
put compiler flags, rather than munging ac_compile.  libtool is not the 
right place for this sort of knowledge.

> The link tests use $ac_link.  I do not know whether the compiler will 
> select different linker flags and libraries for different $SRCEXT 
> values, but I could imagine this, seeing that compilers _do_ select 
> different values for FLIBS and FCLIBS.  It would mean that libtool has 
> to know the source extension which the user will later use (or maybe the 
> highest one), so that the correct libs can be added to shared library 
> deplibs. Hmm, maybe we should just require the user to put AC_FC_SRCEXT 
> before AC_PROG_LIBTOOL/LT_INIT?

What if the user mixes code with more than one extension?  e.g. some .f90 
files and some .f95 files?  This needs to work too.

I think the most reasonable course, for now, is to assume that a given 
compiler name $FC always uses the same libs; if we find a specific case 
where this fails we can find a workaround, but it is impractical to 
work around completely hypothetical failures, especially since it's not 
clear what the solution should be.

(Differences between $FLIBS and $FCLIBS probably stem from $FC being 
different from $F77.)

> > > 2) For an eventual test suite addition, should I use `.f90' (so Automake
> > > plays halfway well) and AC_FC_SRCEXT([.f90]), or stick fo `.f'?
> >
> > It depends on what your test suite needs to do?
>
> It should test creating shared libraries with Fortran code and mixed
> Fortran/C code and a program that uses them.  Maybe also Fortran 77/
> Fortran, but I suspect that will be less of an issue in practice.

I would stick with the autoconf default (.f, or whatever the user 
selected).

> > A workaround is to set F77=$FC and FFLAGS=$FCFLAGS
>
> Not good.  Recent automake also issues `--tag=F77' resp. `--tag=FC' for
> the libtool command line.  We need this to be correct as well so libtool
> selects the right flags.

If FC=F77, then why shouldn't --tag=F77 be okay?

In any case, any more sophisticated fix relies on automake being fixed. 
It should use FC for .f files if AC_FC_SRCEXT(f) was called by the user.

> > Adding it to FCFLAGS will almost certainly cause other failures (because
> > e.g. FCFLAGS are used for linking as well as for compiling).
>
> This is one question I did not know but have not tested thoroughly yet.
> Do you know of a system where this fails?

I suspect the Intel compiler will fail.  -Tf tells it that the next thing 
on the command line is a Fortran source file, and if it isn't I seem to 
recall an error occurring.  (The Intel compiler is the whole reason that 
the AC_FC_SRCEXT documentation insists that its flag go immediately before 
the source file.)

Steven