How to create tests for FC?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

How to create tests for FC?

Ralf Wildenhues
I am trying to put FC support in Libtool, and encounter a problem
similar and not quite orthogonal to Steven's suggestion for Automake[1].
Actually, more than one:

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?
Do I need to specify several source files for freeform/not-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'?

Regards, and thanks for any help,
Ralf

FYI, some notes gathered (no guarantee on correctness):
- Intel ifc/ifort dislikes extension `.f95'.
- AIX xlf90/xlf95 dislikes extension that does not fit name.
- Some compilers decide freeform/language level based on extension,
  some on which name they are called by.
- Automake chooses $(F77) for `.f'.  Workaround?
- Automake needs to use $(FCFLAGS_$EXT) as mentioned in [1].  Wait for
  solving this or add to $(FCFLAGS) as workaround?
- Some compilers insist on either freeform or not and will reject the
  other one.

[1] http://lists.gnu.org/archive/html/automake/2005-06/msg00012.html


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|

Re: How to create tests for FC?

Steven G. Johnson
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?

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).  Your
tests should also normally use AC_COMPILE_IFELSE which uses the current
extension and flags (if any).

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.

> 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?  You should either use
.f or use .f90 with AC_FC_SRCEXT(f90).

> FYI, some notes gathered (no guarantee on correctness):
> - Intel ifc/ifort dislikes extension `.f95'.
> - AIX xlf90/xlf95 dislikes extension that does not fit name.

Yup, this is already noted in the AC_FC_SRCEXT code.  In fact, those two
compilers (grrr) were the reason for this macro.

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

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

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

Cordially,
Steven G. Johnson



_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|

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


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|

Re: How to create tests for FC?

Stepan Kasal
Hi,

On Tue, Jun 07, 2005 at 08:59:27AM +0200, Ralf Wildenhues wrote:
> It might be helpful if they got a patch.  :)
> But seriously, I believe they read this list as well.

don't be so sure.  If you have a problem with automake, ask
on automake list.  If it is a bug, report it to bug-automake.
If you get no answer for a month, repeat.

And if someone else has a similar problem, they'll search it in the
archives of the Automake list; they wouldn't find it in Autoconf archives.

Have a nice day,
        Stepan


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|

Re: How to create tests for FC?

Steven G. Johnson-2
In reply to this post by Ralf Wildenhues
>> 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


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|

Re: How to create tests for FC?

Ralf Wildenhues
In reply to this post by Stepan Kasal
Hi Stepan,

* Stepan Kasal wrote on Tue, Jun 07, 2005 at 03:36:19PM CEST:
> On Tue, Jun 07, 2005 at 08:59:27AM +0200, Ralf Wildenhues wrote:
> > But seriously, I believe they read this list as well.
>
> don't be so sure.  If you have a problem with automake, ask
> on automake list.  If it is a bug, report it to bug-automake.
> If you get no answer for a month, repeat.
>
> And if someone else has a similar problem, they'll search it in the
> archives of the Automake list; they wouldn't find it in Autoconf archives.

Yes, most certainly.  Thanks for reminding me.
(I have played by that rule most of the time so far, too, I believe.)

Cheers,
Ralf


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|

Re: How to create tests for FC?

Ralf Wildenhues
In reply to this post by Steven G. Johnson-2
Hi Steven,

* Steven G. Johnson wrote on Tue, Jun 07, 2005 at 11:01:49PM CEST:
>
> 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.

Libtool surely has some rather old cruft which eventually needs to be
cleaned up.  But this code has been in there for years -- I hate to
break things that seem to work and potentially affect every system.

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

OK.  Let's go with that assumption.

*snip more useful comments*

Thanks for your reply.  I have posted a first version of my proposed
patch at <http://lists.gnu.org/archive/html/libtool-patches/2005-06/msg00068.html>.

Regards,
Ralf


_______________________________________________
Autoconf mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/autoconf