Peter,
[sorry for taking a while to respond to this -- it turns out to be a
busy time]
On 2005 Sep 23 , at 18.49, Peter W. Draper wrote:
> I've tried to merge your tagged files onto MAIN and start a
> rebuild, but seem to have hit a problem on the second package (CNF)
> with pre-processing.
>
> This uses the FPP macro to create an include file from the usual
> boiler-plate:
>
> CNF_PAR.processed: CNF_PAR.F
> rm -f CNF_PAR.processed
> $(FPP) -I. $(FPPFLAGS) $(CPPFLAGS) CNF_PAR.F $(FPP_OUTPUT)
> test -f CNF_PAR.processed || mv CNF_PAR.f CNF_PAR.processed
> CNF_PAR: CNF_PAR.processed
> rm -f CNF_PAR CNF_PAR.tmp
> echo "* Generated from CNF_PAR.F by Makefile.am" >CNF_PAR.tmp
> grep '^ .*[^ ]' CNF_PAR.processed >>CNF_PAR.tmp \
> && mv CNF_PAR.tmp CNF_PAR
>
> but under the new system "FPP" doesn't get a value. I think this is
> because the preprocessor checks now determine that direct
> compilation of .F file is possible (using g77 in this case), so
> don't produce the macros to support these games, but maybe my merge
> is messed up to (it felt a bit uncertain in places).
No, you're quite right -- the macro is written with an optimisation
which skips the search for a preprocessor if it turns out that the
compiler can do it internally. It looks like that optimisation is
premature.
Toby -- can you comment? Looking in _AC_PROG_FPP, it looks like the
test is rather simple, and all that would be needed to avoid this
optimisation is for an `assertion' to be removed (an assertion that I
added, to verify the `this shouldn't happen' comment in your code).
However the actual switch is in AC_PROG_FPP at line 2951 (my heavens,
that file is big!). The questions are:
1. Is the optimisation necessary -- did you get the sense that it
was taking an inappropriately long time to do the usually redundant
step. If so, it might be worth adding a [force] option to the
AC_PROG_FPP macro so that it does this step only when requested.
2. Is the full check possible in the direct compilation
condition? There doesn't _look_ like there'd be a problem, but did
you skip this because you found a problem in fact.
3. The problem of case-insensitive filesystems is currently
shimmied away from, on the grounds that any compiler new enough to be
working on OS X is probably new enough to have built-in
preprocessing. Thus forcing the FPP detection on a Mac will run into
the _AC_FC_CHECK_CIFS check which will, as things stand, cause the
configure to bomb out. Now, we haven't actually had this problem,
because (a) we've been using .fpp as the preprocessable Fortran
extension, and (b) in the case above we're immune to it as we don't
rely on the output file extension being .f. I suppose that one
resolution would be to say that if we have a case-insensitive FS,
then the only preprocessors which are acceptable are those for which
FPPOUTPUT=>$@, producing their output on stdout rather than to a
file. Again, this condition will probably be true in all cases where
it is relevant.
Toby's not subscribed to the stardev list, and I think the list is
configured so that non-subscribers can't post. Perhaps best is to
take this off-list, and between me, Toby and Peter
<[log in to unmask]> -- yes? Anyone else?
See you,
Norman
--
----------------------------------------------------------------------
Norman Gray / http://www.astro.gla.ac.uk/users/norman/
Physics & Astronomy, Glasgow University, UK
|