Re: hppa2.0-hp-hpux10.20 mixed Fortran and C

[Steve Edwards]

On Wed, 2006-08-23 at 15:29 +0200, Ralf Wildenhues wrote:

> Automake has some support for preprocessed Fortran 77.  Could you try
> whether that is sufficient for you, and if not, please describe what is
> missing (I am trying to whip up Fortran support a bit at the moment...)?
> Please see the Automake documentation for details.

I'll have a look through and see what is available. I'm glad Fortran
support is still being pushed ;-)

One point that does spring to mind is the IBM xlf/xlf90 compiler that
rejects -DDEFINE. You have to pass the -D option via -WF,-DDEFINE with
that compiler as far as I understand it. The -D is used for compiling
lines of fixed source form Fortran code that have a D in column 1.

The conditional appeared to be an easy way of generating pre-processed
source bypassing the compiler.

> What do you need the @EXTRA_FLAGS@ for?

Legacy. Personally I'd rather just remove it. Maybe if I can find a
large enough stick...

> If no flag is know to the
> > configure script it uses an automake conditional to generate
> > pre-processed Fortran:
> > 
> > if PPHASH
> > .f.o:
> >     $(FTNPP) $(FTNPPFLAGS) @DEFINES@ $(AM_CPPFLAGS) `test -f '$<' || echo
> > '$(srcdir)/'`$< > $(*F).F && $(F77COMPILE) -c -o $@ $(*F).F
> > endif
> 
> Besides the fact that I think Automake does not cope well with
> conditional overrides of inference rules, I believe you need to override
> the rule for `.f.lo' as well, for files handles by libtool.  I think
> this is the cause for the error you see (untested).

Well, I assembled a stripped down library and of course that worked
fine! As soon as I added the pre-processing conditional though it was
back to the same problem - you are quite correct, it is indeed the
pre-processing section.

Manually adding .f.lo did correct it with warnings regarding overriding
commands for target `.f.o'

If the automake conditional was re-enabled with an entry for .f.lo: then
automake very kindly commented out the entries

.f.o:
        $(F77COMPILE) -c -o $@ $<

.f.lo:
        $(LTF77COMPILE) -c -o $@ $<

that would other wise have been present and *that* caused the error to
resurface. Uncommenting these lines resulted in the warnings regarding
overriding commands again but this time it built perfectly fine.

Completely hidden on most platforms but crept out of the woodwork to
bite me on hppa2.0.

> > If a flag is known it sets FPPFLAGS, but this has to be set for the
> > compile stage only and not the link stage - g77 uses -xf77-cpp-input and
> > fails if you leave this in the command line at link time as then it
> > tries to pre-process the object code.
> 
> See above, that should be a non-issue if you use file names ending in
> .F, given that Automake does the preprocessing logic correctly then.
> Automake will use
>   PPF77COMPILE = $(F77) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
>           $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_FFLAGS) $(FFLAGS)
> 
> for compilation.  If that is a problem with colliding *CPPFLAGS for
> C/C++ files compiled from the same Makefile.am, you could just compile
> them in a different directory as a workaround.

PPF77COMPILE I didn't know. Thanks.

Thanks for your help and hints on this problem - it looks like the
correct fix would be to switch to using .F and let automake deal with
the pre-processing.

Steve