autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fortran 90/95 support (autoconf)


From: Akim Demaille
Subject: Re: Fortran 90/95 support (autoconf)
Date: 08 Jun 2001 19:39:35 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)

| Hello!

Hi!

| There was some earlier (about a year ago or so) attempt to provide a
| solution by Martin Wilck for autoconf; but his macros ceased to work
| as the autoconf development is *so* rapid. 

Used to be.

| Thus, I've put together
| my own stuff to use both autoconf and automake for my mixed
| C/f77/f90/f95 projects. I have used this for several month now in
| about ten different packages, and they seem to work well - at least for
| me...

This is excellent news!

| I have just send the patches for automake to the automake list;
| here's a patch for autoconf's aclang.m4. In contrast to Martin's
| approach I have only tried to provide a minimalistic support for
| fortran 90 and 95. There is no solution for automatically finding
| dependencies; no tests to find out how fortran 90 modules are handled
| (i.e., if special command line switches need to be given in order to
| activate module support, or how to specify paths to external modules
| etc.); and there are probably many other missing features.

Nonetheless, I'd really love to hear from Martin.

| Thus, I would like to request to include the attached patch to
| autoconf (and the corresponding patch to automake). If the maintainers
| of these packages agree to include them, I would try to write some
| description for the manuals and / or provide some working examples.

I'm very happy with your contribution.  I plan to release 2.51 soon,
which must be a bug fix release mainly.  Given that your only
addressing new features, I have no problems with integrating them (but
a few things, listed below) for 2.51 though.

| The patch defines the following new macros (which have similar
| meanings like their Fortran 77 counterparts):

That was the point :)

| I'm somewhat ambivalent about the AC_F90_WRAPPER and related macros
| since I have actually never used the autoconf mechanism for mangling C
| and fortran code. Based on my limited understanding on how compilers
| work, I would expect that the name mangling will only work for plain
| fortran 77 style subroutine and function calls, but certainly not for
| the more advanced generic and array features of the fortran 90
| language which are available through explicit interfaces. But then,
| corresponding macros are available for F77, so there are people using
| them... Again, these macros have not been tested.

Well, releasing Autoconf is a good means to get some feedback :)

| 2001-06-07  Christian Marquardt  <address@hidden>
| 
|       * aclang.m4: (AC_LANG(Fortran 90), AC_LANG_FORTRAN90,
|         AC_LANG_SOURCE(Fortran 90), AC_LANG_CALL(Fortran 90),
|         AC_LANG_PREPROC(Fortran 90), AC_LANG_COMPILER(Fortran 90),
|         AC_PROG_F90, AC_PROG_F90_C_O, AC_F90_LIBRARY_LDFLAGS,
|         AC_F90_WRAPPERS, AC_F90_FUNC, *F95*): Added various macros
|         for a basic Fortran 90 and Fortran 95 support.

I would like to suggest that you submit something like acfortran.m4
instead.  Do not import the Fortran 77 stuff, I will, but I think we
should split aclang.m4.

You should submit some form of documentation too, and a NEWS snippet.


| Index: aclang.m4

| +# AC_LANG_FORTRAN90
| +# -----------------
| +AU_DEFUN([AC_LANG_FORTRAN90], [AC_LANG(Fortran 90)])

Don't.  AU_DEFUN is for compatibility with old stuff.  This is new,
just don't define it at all.


| +# AC_LANG_FORTRAN95
| +# -----------------
| +AU_DEFUN([AC_LANG_FORTRAN95], [AC_LANG(Fortran 95)])

Idem.


| +AC_DEFUN([AC_LANG_COMPILER(Fortran 90)],
| +[AC_REQUIRE([AC_PROG_F90])])

Idem.

| +# ac_cv_prog_g90
| +# --------------
| +# We used to name the cache variable this way.
| +AU_DEFUN([ac_cv_prog_g90],
| +[ac_cv_f90_compiler_gnu])

Likewise.


| +AC_DEFUN([AC_PROG_F90],

Make it private.  I.e. _AC_PROG_F90.


| +# _AC_PROG_F90_G
| +# --------------
| +# Check whether -g works, even if F90FLAGS is set, in case the package
| +# plays around with F90FLAGS (such as to build both debugging and normal
| +# versions of a library), tasteless as that idea is.

Do you think this is needed?

| +# AC_PROG_F90_C_O
| +# ---------------
| +# Test if the Fortran 90 compiler accepts the options `-c' and `-o'
| +# simultaneously, and define `F90_NO_MINUS_C_MINUS_O' if it does not.
| +#
| +# The usefulness of this macro is questionable, as I can't really see
| +# why anyone would use it.  The only reason I include it is for
| +# completeness, since a similar test exists for the C compiler.

If you are not sure it is useful, don't include it at all.


| +AU_DEFUN([ac_cv_prog_g95],
| +[ac_cv_f95_compiler_gnu])

Remove.

| +AC_DEFUN([AC_PROG_F95],

Private.

| +m4_define([_AC_PROG_F95_G],

If needed.


| +AC_DEFUN([AC_PROG_F95_C_O],

Similarly.



| +# _AC_PROG_F90_V_OUTPUT([FLAG = $ac_cv_prog_f90_v])
| +# -------------------------------------------------
| +# Link a trivial Fortran program, compiling with a verbose output FLAG
| +# (which default value, $ac_cv_prog_f90_v, is computed by
| +# _AC_PROG_F90_V), and return the output in $ac_f90_v_output.  This
| +# output is processed in the way expected by AC_F90_LIBRARY_LDFLAGS,
| +# so that any link flags that are echoed by the compiler appear as
| +# space-separated items.
| +AC_DEFUN([_AC_PROG_F90_V_OUTPUT],
| +[AC_REQUIRE([AC_PROG_F90])dnl
| +AC_LANG_PUSH(Fortran 90)dnl
| +
| +AC_LANG_CONFTEST([AC_LANG_PROGRAM([])])
| +
| +# Compile and link our simple test program by passing a flag (argument
| +# 1 to this macro) to the Fortran 90 compiler in order to get
| +# "verbose" output that we can then parse for the Fortran 90 linker
| +# flags.
| +ac_save_F90FLAGS=$F90FLAGS
| +F90FLAGS="$F90FLAGS m4_default([$1], [$ac_cv_prog_f90_v])"
| +(eval echo $as_me:__oline__: \"$ac_link\") >&AS_MESSAGE_LOG_FD
| +ac_f90_v_output=`eval $ac_link AS_MESSAGE_LOG_FD>&1 2>&1 | grep -v 
'Driving:'`
| +echo "$ac_f90_v_output" >&AS_MESSAGE_LOG_FD
| +F90FLAGS=$ac_save_F90FLAGS
| +
| +rm -f conftest.*
| +AC_LANG_POP(Fortran 90)dnl
| +
| +# If we are using xlf then replace all the commas with spaces.
| +if echo $ac_f90_v_output | grep xlfentry >/dev/null 2>&1; then
| +  ac_f90_v_output=`echo $ac_f90_v_output | sed 's/,/ /g'`
| +fi
| +
| +# If we are using Cray Fortran then delete quotes.
| +# Use "\"" instead of '"' for font-lock-mode.
| +# FIXME: a more general fix for quoted arguments with spaces?
| +if echo $ac_f90_v_output | grep cft90 >/dev/null 2>&1; then
| +  ac_f90_v_output=`echo $ac_f90_v_output | sed "s/\"//g"`
| +fi[]dnl
| +])# _AC_PROG_F90_V_OUTPUT

Groumph.  I don't like this.  We have to look for a means to share
this across all the languages.  There is too much, way too much, code
duplication.


In fact your contribution is way too big, IMHO.  Could you make it
step by step?  Well, maybe that's too much work, I can understand
this.  Maybe it will be easier to factor once we have it all.


Still, we cannot accept your contribution until the FSF agrees, which
means filling a few papers from the `contributing' pages on
gcc.gnu.org.

Thanks a lot for your contribution!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]