>>>>> "Martin" == Martin Wilck <[EMAIL PROTECTED]> writes:
Martin> Hi there,
Hi!
Martin> The new aclang.m4 structure actually makes implementing the
Martin> f90 support much easier than it was before.
That's the whole point, and I'm happy to see it meets its requirements
:)
Martin> I'd like to inquire how much interest there is to include
Martin> f90-related patches into autoconf (and automake - I also have
Martin> Thomas' patches for that, by have little experience with
Martin> automake).
Plenty!
But, to be honest, I'd say we should not try to do that for the very
next Autoconf 2.50: we are already very late on the schedule. But you
can be sure your patches will make it into 2.51.
Martin> There is at least one technical problem for f90 in the AC_LANG
Martin> structure: The ac_ext variable. This is because f90 compilers
Martin> make different assumptions on file extensions. Although the
Martin> suffix ".f90" is standard, there is at least one compiler
Martin> (xlf90 on AIX) that doesn't accept this suffix (only ".f")
Martin> unless given the "-qsuffix=f=f90" option. Question: should
Martin> macros test for the allowed extension, or should users be
Martin> required to provide a compiler option that makes the compiler
Martin> recognize ".f90" ?
By no way should it be the user. That's probably something easy to
test and set. Just set ac_ext to ac_cv_prog_f90_ac_ext in
AC_LANG(Fortran 90) and compute the latter in AC_PROG_F90. That
should be enough?
Martin> I also have some old macros for extended fortran 77 support,
Martin> most prominently to check for features related to C
Martin> preprocessor/fortran code. Although these certainly need to
Martin> be cleaned up and adapted to the new code structure, they
Martin> might be useful to include in autoconf sooner or later. Again,
Martin> I'd like to know whether there is interest for this in the
Martin> autoconf community.
There is. As soon as several people need to address the same issues,
Autoconf should federate and factor the efforts.
Akim
