On Tue, 27 Sep 2005, Norman Gray wrote:
> [sorry for taking a while to respond to this -- it turns out to be a busy
> time]
Hi Norman,
no worries, your time is clearly yours. Hope the business is down to good
things.
> 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?
OK, thanks now I can see the problem, a little hack later and I've sent my
build off again. I'd imagine Tim might want to keep an eye on this (his
mail may be a little uncertain for the next couple of weeks).
Cheers,
Peter.
|