| 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.
See the patch: f77 is preferred. It is more discriminant. But I
might be wrong, I don't really have a strong Fortran experience :)
| 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.
This explicitly means no project can have 77 and 90 sources.
| 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).
This is what I was thinking about. This script is `compile', shipped
with Automake.
Or maybe we should make zillions of symlinks?
I didn't think about the debugging issue.
| Well, perhaps I've simply overlooked a general, portable, elegant,
| and easily-implemented solution to this problem.
I think you have much insight :)
| 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 ...
Can't we always use this? I mean, how do Make's behave on
me: me
echo foo
Or just
@F77_INEXT_IS_NOT_f77@.77.@(F77_IN_EXT):
@F77_INEXT_IS_NOT_f77@ cp $< $@
.$(F77_IN_EXT).o:
$(F77) $(FFLAGS) ... $<
where @F77_INEXT_IS_NOT_f77@ would evaluate to `#' or nothing.
