Dear Akim Demaille, you wrote on Today:
> Maybe we should AC_SUBST the result? This might be important for
> Automake to see if it needs a wrapper for compilers which refuse the
> traditional extensions?
> I've tested this patch like this:
>
> /tmp % cat /tmp/f77 19:35 remo
> #! /bin/sh
>
> case "$@" in
> *.f77*) echo "$0: unrecognized: $@" >&2
> exit 1;;
> *.f*) echo "$0: I love this: $@" >&2
> cp `which true` conftest.o
> cp `which true` conftest ;;
> *) echo "$0: didn't understand this: $@" >&2;;
> esac
You should have tested the opposite case - it becomes interesting
when the compiler does not accept the standard extension.
> Is it possible that different compilers on the same platform use
> different exeext and objext? If so, then maybe this macro,
> _AC_LANG_COMPILER_INEXT should become _AC_LANG_COMPILER_EXT and
> compute the three extensions?
I dare express an opinion here because I pondered a lot about these
problems when dealing with F90 stuff (I reported that xlf doesn't support
.f90 by default), and also some aspects of my Fortran/experience is
related (does the compiler accept and properly handle .F-files?)
Your macros are fine, but it becomes difficult from the make/
automake perspective.
To make the long story short: I think this is very dangerous terrain,
and would mean an awful lot of effort for both autoconf
and automake people to make it work. If this is just for supporting
some exotic compilers, IMHO it isn't worth the effort.
Here comes my argument:
- maintainers need to put their source with some extension.
The standard (e.g. ".f" for F77) can't be so bad a choice.
- If we find a compiler that doesn't support a standard, and find
another one it accepts (".f77" for F77, to stick with your example),
we have 4 possibilities:
1 ) use a complex value for F77COMPILE, something like
{ cp $< $*.$(F77_INEXT); $(F77) $(FFLAGS) ... $*.$(F77_INEXT); rm -f
$(F77_INEXT) }
this has two strong disadvantages: debugger usage will be broken,
because a debugger can't find the source files, and we need
similar rules for generation of libtool objects as well. It was when
I looked at the libtool rules that I cowardly refused to go that way
for F90.
2 ) use a wrapper script that does the above pipe internally,
with a normal compiler-like invocation procedure, and set $F77 to
that script. This still has the debugger problem, but gets rid of
the libtool problem. However, writing such a script seems to be
difficult, since you'd need to parse all the command line
options and arguments and properly pass them to the "real" compiler.
Command line options can have widely different syntax
(e.g. -R/directory on one system and -R /directory on another), and
so on. I had started an attempt to write an "F90" wrapper, but gave
up when I relaized the complexity.
Anyway, if somebody succeeds in writing a suitable tool, that
would probably be the most robust solution. The debugging problem,
however, persists. (And Tom just wrote yesterday that he doesn't
like the idea of additional helper scripts too much).
3 ) Generate two-step make rules, like this:
.f.f77:
cp $< $@
.f77.o:
$(F77) $(FFLAGS) ... $<
Here we can get rid of the debugging problem by telling make
not to delete intermediate files.
Generating this with automake is tricky, however, since we
certainly want the original .f.o rule for compilers that do
support ".f". We must therefore find a way to conditionally
generate make rules, and we need to do this portably, which is
hard.
To make matters worse, practically all makes have builtin rules
for .f.o which cannot be overridden by the above construct.
For Gnu make at least, an empty ".f.o" rule does not cancel
the builtin rule, you'd need to use a non-portable "%.f%.o"
pattern rule instead.
I had the same problem for F77/cpp, and the only portable way
to override the builtin rule I could find was to generate
an explicit rule for each and every ".f" file. This is possible,
but results in quite unelegant Makefiles. Since automake doesn't
know if the compiler will support ".f", it needs to output these
explicit rules in any case.
4 ) The lazy approach: For each compiler reported that doesn't support
the standard extension, find a compiler option that changes this
behaviour. Drop support for compilers that don't have such an option.
I plan to go this way for f90, since inquiry on comp.lang.fortran
assured me that xlf is the only compiler behaving so, and I know
the option for xlf to make it accept ".f90".
Well, perhaps I've simply overlooked a general, portable, elegant,
and easily-implemented solution to this problem.
I'd be happy if somebody comes up with one.
IMHO, 1-3 all come down to automake/autoconf people putting an enormous
programming effort to work around what I'd call compiler bugs (not to
support a standard source file extension). That's another reason why I
know favour option 4). 4) is a bad solution if it turns out
that a large user base would be left without auotools support.
But these people currently don't enjoy that support anyway.
Finally, I see a last solution
that would be elegant, but possibly would break all backward
compatibility.
automake could use it's own non-standard suffixes for source files
of any language (".amf77", for example) and automatically generate
rules like
.amf77.@(F77_IN_EXT):
cp $< $@
.@(F77_IN_EXT).o:
$(F77) $(FFLAGS) ... $<
This would elegantly avoid the problem with builtin make rules,
but package maintainers would probably be quite unhappy to have to
rename all their source files. Moreover, we need to support
OS's supporting only 3-chjaracter file suffixes ...
Regards
Martin
--
Martin Wilck <[EMAIL PROTECTED]>
Institute for Tropospheric Research, Permoserstr. 15, D-04318 Leipzig, Germany
Tel. +49-341-2352151 / Fax +49-341-2352361
