Re: 25-ac-lang-compiler-inext

gt; .$(F77_IN_EXT).o: > $(F77) $(FFLAGS) ... $< > > where @F77_INEXT_IS_NOT_f77@ would evaluate to `#' or nothing. That's a beautiful solution. But some doubts (maintainers have to rename all their files, performance and resource usage) remain. Martin -- Martin Wilck <[EMAIL PROTECTED]> Institute for Tropospheric Research, Permoserstr. 15, D-04318 Leipzig, Germany Tel. +49-341-2352151 / Fax +49-341-2352361

Re: 25-ac-lang-compiler-inext

enerate 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

Re: -c -o

.o: $(CC) $(CFLAGS) ... @CC_C_O@ $< where CC_C_O would either be "-c -o $@" or simply "-c". -- Martin Wilck <[EMAIL PROTECTED]> Institute for Tropospheric Research, Permoserstr. 15, D-04318 Leipzig, Germany Tel. +49-341-2352151 / Fax +49-341-2352361

Re: Fortran dependency tracking

if these fetaures are desired on the maintainers' part, - if the style is basically ok. And, of course, I'd be interested to know if "a long wait" means days, weeks, months, or years, and if I'll have to resubmit my patches when the time has come. I intend to help, no

Re: Fortran dependency tracking

equire package maintainers to replace INCLUDE 'file' by #include "file" which comes down to a "regexp replace in directory" command in emacs. The result would certainly be as portable as before, because everybody will be able to get his hands on some variant of cpp.

Re: Fortran dependency tracking

to have yet-another-helper-tool in addition to mkinstalldirs, depmod, etc.? As long as we keep it simple, portable, and short, of course. Regards, Martin -- Martin Wilck <[EMAIL PROTECTED]> Institute for Tropospheric Research, Permoserstr. 15, D-04318 Leipzig, Germany Tel. +49-341-2352151 / Fax +49-341-2352361

Re: Fortran dependency tracking

we can't assume one to be available for all maintainers. 2 - As stated above, there is no compiler-independent way to associate modules with file names. Problem 2) may probably be avoided by generating dependencies only for object files (just thinking aloud :-) Regards, Martin -- Martin Wilck <[EMAIL PROTECTED]> Inst. for Tropospheric Research, Permoserstr. 15, 04303 Leipzig, Germany

Fortran dependency tracking

at all in automake/autoconf, - if yes, which solution we should go for ? Regards, Martin P.S. This problem seems to be trivial compared to providing dependency tracking support for Fortran 90 modules. But that's a different issue... -- Martin Wilck <[EMAIL PROTECTED]> I

-c -o

ds for C/C++, unless I'm completely mistaken. If such a test can make sense, then automake must provide a configure variable that autoconf can insert in the Makefile in order to assert correct compilation behaviour, right ? Regards Martin -- Martin Wilck <[EMAIL PROTECTED]> Inst

Automake patch: improved fortran/cpp support

trol whether .F files are to be compiled directly into object files with a sufficiently smart compiler, or whether independent preprocessing is used to produce "pure" fortran (.f files) first (if the compiler understands no or only rudimentary cpp). Regards, Martin -- Martin Wilck <[EMA

Re: autoconf fortran 90 support

ary to use the same compiler for f77 and f90 source. Actually, autoconf/automake must detect this case, and take special measures to handle it. This would probably imply a lot of further complications with make and automake rules. -- Martin Wilck <[EMAIL PROTECTED]> Institute for Tropospheric Research, Permoserstr. 15, D-04318 Leipzig, Germany Tel. +49-341-2352151 / Fax +49-341-2352361