autoconf-patches
[Top][All Lists]
Advanced

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

Support for preprocessable Fortran in autoconf/automake


From: Norman Gray
Subject: Support for preprocessable Fortran in autoconf/automake
Date: Wed, 21 Jan 2004 15:01:55 +0000 (GMT)

Greetings,

[Bcc to Martin Wilck]

I've assembled a set of patches to autoconf-2.59 and automake-1.8.2,
to support preprocessable Fortran.  The changes consist of:

  * Automake support for autoconf's FC macros, as contributed by
    Michael Nolta here recently [1].

  * Autoconf support for preprocessable Fortran, which Martin
    Wilck posted to autoconf-patches in 2000, but which never made it
    into the main source [2].

  * Automake support for Martin's patches.  This is ultimately derived
    from Martin's automake patches [3], but automake has changed
    sufficiently from then that this code is essentially all new.

Martin's autoconf patches are largely unchanged from his 2000 submission,
but there are a few changes of detail.  One class of those is in response
to the comments Akim made in the thread after [2].  In particular,
I've kept the cstyle/CSTYLE material for completeness, though I think
Martin agreed with Akim that it was probably unnecessary, and painlessly
removable.  I've also retained Martin's interface to the AC_PROG_FPP
macro, which requests autoconf to check for a configurable set of
properties that an acceptable fpp program must have.  Though this is
different from usual autoconf macro behaviour, and pace the discussion
in [2], I think this is important and useful for reasons which I can
elaborate on, and which were touched on in the [2] thread.  There are
a few other smaller additions and modifications I've made.

So.  What to do next?

I'm not currently in a position to test this support on the range of
platforms and Fortran compilers that it would need, so I'd need some
help with that before this could be a serious candidate for inclusion
in autoconf and automake.  I therefore suggest that, rather than post
the patches and so risk letting them `into the wild', I mail them to
anyone who can review or test the changes -- does that sound reasonable?

If so, what's the best way to modify the version numbers to indicate that
this is a temporary fork/patch?  Automake has useful support for a -FORK
portion in its version number, but m4sugar's m4_version_compare gets very
confused at anything other than a single letter after the version number.

The documentation for the AC_PROG_FPP macro is as follows:

# AC_PROG_FPP([required features], [FPP-SRC-EXT=.fpp])
# --------------------------------------------------
#
# [required features] is a space-separated list of features that the Fortran
# preprocessor must have for the code to compile.
#
# [FPP-SRC-EXT] is an optional specification of the file extension for
# preprocessable Fortran source files (without a leading dot).  It
# defaults to `fpp', which is better than .F in general, since .F and
# .f are indistinguishable on case-insensitive filesystems (such as
# HFS+ on MacOS X).
#
# It is up to the package maintainer to properly set these requirements.
#
# Supported features are:
#
# include   : correctly process #include directives and -I
# define    : correctly process -D
# substitute: substitute macros in Fortran code 
#             (some preprocessors touch only lines starting with #)
# wrap      : wrap lines that become too long through macro substitution  
#             fpp is probably the only preprocessor that does this.
# cstyle    : Do not suppress C style comments (-C option in cpp)
# CSTYLE    : *Do* suppress C style comments
#             (e.g. code contains C-style comments, and compiler may not
#             know how to handle them)
# 
# Features can be abbreviated: i, in, inc etc. are equivalent to include.
# Features can be deselected (feature not needed) by prepending "no", 
#   e.g. nodef (=nodefine), now (=nowrap).
#
# Default for the feature list is 
#       [include define substitute nowrap nocstyle noCSTYLE]
# Feature requirements corresponding to the defaults may be omitted
#
# Note that "wrap" implies "substitute", and CSTYLE and cstyle cannot
# be requested at the same time. The macro adjusts this automatically. 
#
# This macro sets and substitutes the variables FPP and FPPFLAGS, and
# causes to be set FPP_OUTPUT, FPP_MAKE_FLAGS, and FPP_COMPILE_EXT
# (actually set in macro _AC_FPP_BUILD_RULE)
#
# The macro depends on both F77 and CPP, because we must possibly fall 
# back on CPP for preprocessing.
#

I haven't yet added proper documentation to the .texi files in either
distribution.  There are a couple of new `FIXME' remarks in the patches;
I'd welcome clarification on the points discussed there.

I hope this is useful, and that we can find a way of getting this support
into the main automake and autoconf sources.

Best wishes,

Norman



[1] http://www.mail-archive.com/address@hidden/msg07811.html
    [note that the archive unhelpfully obfuscates the `automake at-sign
    gnu.org' in this line]
[2] http://sources.redhat.com/ml/autoconf-patches/2000-07/msg00287.html
    ...and following thread
[3] http://sources.redhat.com/ml/automake/2000-07/msg00043.html

-- 
---------------------------------------------------------------------------
Norman Gray                        http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK     address@hidden





reply via email to

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