Re: Fortran dependency tracking
Martin> I understand you're trying to get a new release out. It isn't that. It's just that I (and, apparently, the other automake hackers) have very little time. Tom
Re: Fortran dependency tracking
Dear Tom Tromey, you wrote on Today: > You might be in for a long wait, sorry. I understand you're trying to get a new release out. I certainly don't want to interfere with that, nor put any sort of pressure upon you or other maintainers. At present I'd mainly like to know - 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, not bother anybody. 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
Martin> Last comment: If some day my Fortran/cpp patches get accepted Martin> in some form for the autotools (btw: I'd appreciate some Martin> feedback from the automake maintainers on the patch I Martin> suggested) You might be in for a long wait, sorry. Tom
Re: Fortran dependency tracking
Dear Tom Tromey, you wrote on Today: > We already handle this for C compilers. It just means writing a lot > of cases. Fine, but as I said, for 9 out of 10 compilers users would see the message: Checking for dependency style of f77 ... none which is probably not what we want. > Don't let me discourage you though. If you can make it work I'm sure > we'll use it... Thanks :-) Akim > In particular if you consider the lexical flexibility of Akim > Fortran. It Akim > is reasonable to require a particular form of include/INCLUDE Akim > etc. from the maintainers who are making the effort of using Akim > Autotools to get some portability. With that in mind, writing a simple tool should actually be easy. I just wonder whether a portable shell scipt or a (probably) more powerful but less portable perl program would be preferrable. Last comment: If some day my Fortran/cpp patches get accepted in some form for the autotools (btw: I'd appreciate some feedback from the automake maintainers on the patch I suggested), we would have a portable way of handling include files and the corresponding dependencies through cpp. Implementing that would be trivial. This option becomes even more attractive by the fact that INCLUDE is not part of the Fortran 77 standard (learned that yesterday from somebody on comp.lang.fortran), it's just a "de-facto"-Standard which most compilers support. It might be justifiable to require 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. -- 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
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: Tom> Also, writing a dependency tool in a portable way seems hard. In particular if you consider the lexical flexibility of Fortran. It is reasonable to require a particular form of include/INCLUDE etc. from the maintainers who are making the effort of using Autotools to get some portability. See C for instance: ansi2knr requires that you follow some rules in your sources. Feel free to ask the same from the Fortran people.
Re: Fortran dependency tracking
Martin> Wrt to supporting every compiler, let's forget about it. So Martin> far I haven't seen a single compiler with decent dependency Martin> tracking support. And even if they did, you can be certain Martin> that each and every one would use a different option syntax Martin> and output format. We already handle this for C compilers. It just means writing a lot of cases. Martin> Wrt the tool: why would it be so bad to have Martin> yet-another-helper-tool in addition to mkinstalldirs, depmod, Martin> etc.? As long as we keep it simple, portable, and short, of Martin> course. There are already too many mini-tools. Also, writing a dependency tool in a portable way seems hard. Don't let me discourage you though. If you can make it work I'm sure we'll use it... Tom
Re: Fortran dependency tracking
Dear Tom Tromey, you wrote on Yesterday: > Actually, ideally we'd like to support every compiler. However, I > think we'd also rather avoid distributing a complete Fortran > dependency-finding tool with every Fortran-using package. This is > hardly ideal, I guess. Wrt to supporting every compiler, let's forget about it. So far I haven't seen a single compiler with decent dependency tracking support. And even if they did, you can be certain that each and every one would use a different option syntax and output format. Wrt the tool: why would it be so bad 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
Martin> If I understand the automake philosophy right, then it Martin> suffices to support only a few compilers, generate the Martin> dependencies on the maintainer's site, and include them into Martin> the distributed Makefiles. Actually, ideally we'd like to support every compiler. However, I think we'd also rather avoid distributing a complete Fortran dependency-finding tool with every Fortran-using package. This is hardly ideal, I guess. Tom
Re: Fortran dependency tracking
On Mon, 17 Jul 2000, Tom Tromey wrote: > Could you submit a bug report to the automake Gnats? Mark it > "critical/high". We need to fix this before the next release. > There should be a link to Gnats from http://sourceware.cygnus.com/automake/ > Thanks. Just sent it in. I just discovered that including AC_PROG_CC in configure.in also "solves" the problem. > I think the goal here should be to have the Fortran compiler generate > the include information -- it can list both the files included via > #include and those included via INCLUDE. This way you get complete > dependency tracking as a side effect of compilation. > Writing a patch to g77 to do this shouldn't be all that hard. Well, well - perhaps not. I don't know if I can do it, though. Will take some time in any case. > Martin> - if yes, which solution we should go for ? > > When possible, fix the compilers. When not possible, maybe living > with less than perfect information is the only approach. > > Martin> P.S. This problem seems to be trivial compared to providing > Martin> dependency tracking support for Fortran 90 modules. But > Martin> that's a different issue... > > This should also be solvable if the compiler is intelligent. I have tested quite a few compilers recently, and for none I found an option that would do what you suggest :-( "The compiler" is a difficult term here, as every compiler treats modules differently. They can't even agree whether module file names should be generated from module names or source file names. For example, from a file "foo.f90" containing MODULE bar END MODULE bar one compiler would generate a module file "foo.M", the other "bar.mod", yet another "BAR.mod", and again another two files, "bar.vo" and "Vfoo.inc". (These are real examples). If I understand the automake philosophy right, then it suffices to support only a few compilers, generate the dependencies on the maintainer's site, and include them into the distributed Makefiles. For Fortran 77, making g77 report correct dependencies would therefore suffice. However, for Fortran 90 we'd have two problems: 1 - unfortunately, there is no available public domain F90/F95 compiler, so 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
Re: Fortran dependency tracking
I removed the autoconf list from the followups. Dependency tracking doesn't involve autoconf. Martin> First of all, an automake-generated makefile refuses to work Martin> if there is no C source file specified in Makefile.am (only Martin> Fortran source files). Could you submit a bug report to the automake Gnats? Mark it "critical/high". We need to fix this before the next release. There should be a link to Gnats from http://sourceware.cygnus.com/automake/ Thanks. Martin> Unfortunately, that approach doesn't work for Fortran INCLUDE Martin> statements, and I have not yet found a tool that parses such Martin> statements like e.g. makedepend parses #include's. I think the goal here should be to have the Fortran compiler generate the include information -- it can list both the files included via #include and those included via INCLUDE. This way you get complete dependency tracking as a side effect of compilation. Writing a patch to g77 to do this shouldn't be all that hard. Martin> - whether such a thing like Fortran dependency tracking is Martin> desirable at all in automake/autoconf, Yes. Martin> - if yes, which solution we should go for ? When possible, fix the compilers. When not possible, maybe living with less than perfect information is the only approach. Martin> P.S. This problem seems to be trivial compared to providing Martin> dependency tracking support for Fortran 90 modules. But Martin> that's a different issue... This should also be solvable if the compiler is intelligent. Tom
Fortran dependency tracking
I'd like to draw your attention to the following problem: There is one thing the autoconf/automake support for Fortran 77 is currently lacking: dependency tracking like for C/C++. First of all, an automake-generated makefile refuses to work if there is no C source file specified in Makefile.am (only Fortran source files). The reason is that the Makefile contains dependencies on .deps/whatever.Po which doesn't exist, but has no rule for generating these. Once a single C source file exists in the same directory, the problem disappears. I have not understood the dependency tracking code for C/C++ well enough yet to fix this. Second, if the Fortran/cpp code became part of autoconf, it would be relatively easy to track Fortran dependencies resulting from cpp #include statements. Basically, the same approach as for C/C++ could be used (g77 supports -MM and -MD, and fpp supports -M with very similar outcome. "makedepend" also works with Fortran input files). Unfortunately, that approach doesn't work for Fortran INCLUDE statements, and I have not yet found a tool that parses such statements like e.g. makedepend parses #include's. It would be relatively simple to provide e.g. a simple perl script taking care of this. Such a script, however, would only recognize basic syntax. The following code: I Nclu De 1'i3.in 2c' which is valid Fortran 77 syntax for including a file called 'i3.inc', would certainly not recognized by a simple script, which would probably parse for something like ^ *[iI][nN][cC][lL][uU][dD][eE] *["']\(.*\)["'] In order to do it right (so that any valid Fortran INCLUDE be recognized), one would need (almost) a fully-fledged Fortran parser, and I cowardly refuse to start writing one (I have considered stripping down the parsers of either f2c or g77, but even that looks like a huge amount of work). Could anyone comment on - whether such a thing like Fortran dependency tracking is desirable 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]> Institute for Tropospheric Research, Permoserstr. 15, D-04318 Leipzig, Germany Tel. +49-341-2352151 / Fax +49-341-2352361
