Folks,
I've been working on the dev-nxg-20040116-add-fpp-support branch of
both autoconf and automake, to get it to a point where it's in a semi-
releaseable state. That means that the code is reasonably consistent
and clean, all the regression tests now work for both autoconf and
automake, with some additions and some changes, and the documentation
for both is in a decently readable state.
This branch has seen a few changes, with important changes being to
autoconf/lib/autoconf/fortran.m4 and automake/automake.in. I've put
rolling summarise-commits output at <http://cvs.starlink.ac.uk/~nxg/
summarise-commits-fsf-28day.html> -- this will display the commits
for the thirdparty/fsf tree for the last 28 days.
There are two sets of interface changes.
1. There are some changes to the fortran.m4 macros, so that
- AC_FC_SRCEXT is now deprecated, and replaced by AC_FPP_(FREE|
FIXED)FORM (see the docs)
- the default preprocessable-Fortran extension is now .F rather
than .fpp -- this should be OK, since we've moved away from .fpp
to .F, haven't we?
These will predominantly affect the Starlink folk, since the
interface changes are mostly Toby's, forced by his experience of a
broad variety of Fortran compilers.
One change might affect Toby, however. I've modified the default set
of features for the AC_PROG_FPP macro: it now doesn't require macro
substitution (option `nosubstitution'), and I've disabled the
abbreviating of features. I feel that the default set should be as
limited as possible, to the point where a fairly simple script could
potentially do the work; if you feel strongly that `substitute'
should still be there, feel free to revert this.
This might affect both: the extension .f is now back to being
associated with the F77 interface, where I had it associated with the
FC interface before. The latter is better, but I'd prefer to avoid
too many backward incompatible changes in the submission. If you set
AUTOMAKE_F_IS_FC=1 in the environment, however, .f will be associated
with FC as before.
2. The `output' of the fortran.m4 macros has changed quite
significantly, so that the canonical way of using the results is
something like
@[log in to unmask]@[log in to unmask]:
@FPPDIRECT_TRUE@ $(PPFCCOMPILE) -c -o $@ $<
@[log in to unmask]@[log in to unmask]@FPP_COMPILE_EXT:
@FPPDIRECT_FALSE@ $(FPP) $(DEFS) $(DEFAULT_INCLUDES) \
@FPPDIRECT_FALSE@ $(INCLUDES) $(FPPFLAGS) $(AM_CPPFLAGS) \
@FPPDIRECT_FALSE@ $(CPPFLAGS) $< @FPP_OUTPUT@
rather than the inelegant, complicated and errorprone switching of
extensions that was there before. This will predominantly affect
Toby, since I've made corresponding automake changes so that this is
what is generated automatically in generated Makefile.in files. The
Starlink folk _shouldn't_ notice any changes here, therefore. Toby:
you might have to tweak some Makefile.in files.
The next stage is to test that this most recent set of changes still
works for both the Starlink tree and for Toby and his colleagues.
I've tagged both thirdparty/fsf/autoconf and thirdparty/fsf/automake
with dev-nxg-20040116-add-fpp-support-fpp6, and additionally put
'make dist' tarballs of the two packages at <http://
www.astro.gla.ac.uk/users/norman/star/dev-nxg-20040116-add-fpp-
support/>. There's HTML and PDF documentation there as well.
Autoconf reports itself as 'Starlink Autoconf', version 2.106, and
automake as `Starlink Automake' 1.9.106 (the 106 matches the fpp6 tag
-- sorry, there doesn't seem to be much room for manoeuvre with the
version numbers)
SO:
1. Can a Starlink person (Peter?) try merging this onto the HEAD and
see what happens.
2. Toby, you mentioned that you had a colleague whom you might be
able to persuade to try this out.
I'd like this to be as much a test of the documentation as the code,
so comments on that are welcome.
If we can iterate this to the point where it seems working and
stable, then I'll turn it into a patch against CVS autoconf and
automake, and finally submit it. Toby says his FSF paperwork is just
about to go through; mine's gone off already, yes, David?
See youse,
Norman
--
----------------------------------------------------------------------
Norman Gray / http://www.astro.gla.ac.uk/users/norman/
Physics & Astronomy, Glasgow University, UK
|