Re: How to create tests for FC?

[Ralf Wildenhues]

Hi Steven, others,

* Steven G. Johnson wrote on Mon, Jun 06, 2005 at 10:27:05PM CEST:
> Ralf Wildenhues wrote:
> >1) Within libtool.m4, a few tests need to be run to find out compiler/
> >linker characteristics.  These may give false failures if the user has
> >set AC_FC_SRCEXT(...) of AC_FC_FREEFORM differently than expected.
> >First: can I find out (without perusing Autoconf internal interface) if
> >they have been called, second may I override them and undo the effects
> >afterwards (how?) without harm, and third which would be the best choice
> >of extension for the test files if not?
> 
> Can you give an example of where you need to undo them and/or where this 
> causes a problem?

If libtool.m4 uses AC_FC_FREEFORM (which is probably unnecessary, as you
mention below) but the user of AC_PROG_LIBTOOL/LT_INIT does not want
free form, I need to undo its effects.  I guess it could be done by
saving and restoring FCFLAGS, and unsetting ac_cv_fc_freeform (although
the latter would not be completely transparent to the user in a cached
run).  But I'll not worry about that for libtool.m4.

AC_FC_SRCEXT is more problematic, in more than one way, see below.

> For example, you can usually format a simple test program so that it 
> will succeed in both a freeform and a non-freeform compiler (indeed, the 
> autoconf macros currently assume this for compiling their tests).

OK, good.  But note that the Libtool tests I am talking about do not
test for exit code only, but also differences in warning messages.  This
is necessary for some compilers which do not fail with unknown options
but only warn instead.  The consequence is that the compiler should give
identical warnings with and without $pic_flag added, for example
(which so far works alright).

> 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.  :(

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?

> That being said, the manual should possibly document a couple of 
> internals to enable more flexibility in the use of these two macros. 
> First, after you call AC_FC_FREEFORM, the $ac_cv_fc_freeform cache 
> variable is set to either the flag (if any), or "none" (if none needed), 
> or "unknown" (if the test failed).  Second, the current source filename 
> extension is stored in $ac_ext and any flags required for $FC are in 
> $ac_fcflags_srcext.  Given this documentation, we should also arguably 
> not modify FCFLAGS in AC_FC_FREEFORM if the user provides an alternate 
> SUCCESS action.

As said: if I can create code that works both ways, I don't care much
about AC_FC_FREEFORM.

> >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.

> You should either use 
> .f or use .f90 with AC_FC_SRCEXT(f90).

I'll probably go with the latter -- that's what I've been testing with
so far, and I assume it exposes problems better than using `.f'.

> >- Some compilers decide freeform/language level based on extension,
> >  some on which name they are called by.
> 
> Usually, .f90 and .f95 files are compiled as freeform...  Hopefully, 
> though, AC_FC_FREEFORM always works if the user needs to guarantee that 
> freeform source is accepted?
> 
> >- Automake chooses $(F77) for `.f'.  Workaround?
> 
> 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.

> >- Automake needs to use $(FCFLAGS_$EXT) as mentioned in [1].  Wait for
> >  solving this or add to $(FCFLAGS) as workaround?
> 
> 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 think you have to accept some failures in the short term until 
> automake is fixed, unfortunately.  (It might be helpful if the automake 
> folks received an additional bug report or two in case I was not 
> persuasive enough.)

It might be helpful if they got a patch.  :)
But seriously, I believe they read this list as well.

Thanks for your insightful comments!

Cheers,
Ralf