[Bug fortran/47495] .mod files: File modification time - Makefile build issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #14 from Eric Gallager --- (In reply to Dominique d'Humieres from comment #13) > Is this still of interest? Guess not.
[Bug fortran/47495] .mod files: File modification time - Makefile build issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-10-13 Ever confirmed|0 |1 --- Comment #13 from Dominique d'Humieres --- Is this still of interest?
[Bug fortran/47495] .mod files: File modification time - Makefile build issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 --- Comment #4 from Ralf Wildenhues rwild at gcc dot gnu.org 2011-01-29 11:48:04 UTC --- For starters it would be nice if gfortran would even document its precise semantics for when module files are created/updated/etc. I'm sure these semantics are not identical across Fortran compilers. This is PR 42607.
[Bug fortran/47495] .mod files: File modification time - Makefile build issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-29 12:02:01 UTC --- (In reply to comment #4) For starters it would be nice if gfortran would even document its precise semantics for when module files are created/updated/etc. I'm sure these semantics are not identical across Fortran compilers. This is PR 42607. These semantics are definitely not identical across compilers, most compilers will always write a .mod if a module is compiled (but some generate even no .mod files or use .MOD or whatever, there is nothing in the Fortran standard that talks about .mod files). However, for me personally, not updating .mod files if they are not changed (and hence providing a way to avoid recompilation cascades) was one of the most important reasons to start using gfortran. It can make development (recompilation) tens of times faster. So, this is absolute a feature to retain in my opinion.
[Bug fortran/47495] .mod files: File modification time - Makefile build issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-29 12:04:10 UTC --- (In reply to comment #4) For starters it would be nice if gfortran would even document its precise semantics for when module files are created/updated/etc. [...] This is PR 42607. In a nutshell: a) When a MODULE is compiled*, gfortran generates a file consisting of the lower-cased module name and the suffix .mod. The file is placed into the current working directory, unless the -J option is used. b) A .mod file is read when a USE statement is encountered; the file must exist and is searched for in the include search paths. c) If a MODULE is compiled again, but an existing .mod file would not change, the file modification date is not modified. d) Module files (.mod) contain the public procedure interfaces, type declarations and module variables of the module, including those made accessible via USE statements within the module [(c) and the second part of (d) are design choices, also the exact data which is saved in the file; the rest nearly all compiler handle in the same way.] [* MODULE = a MODULE module_name; ...; END MODULE block in a file; a file can contain multiple modules - or none.] * * * I think it would be useful to give an example Makefile file in the manual. Joost's solution (comment 2) seems to work fine, though I am not sure how protable to non-Unix platforms the @true is.
[Bug fortran/47495] .mod files: File modification time - Makefile build issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 --- Comment #7 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-29 12:14:26 UTC --- (In reply to comment #6) I think it would be useful to give an example Makefile file in the manual. Joost's solution (comment 2) seems to work fine, though I am not sure how protable to non-Unix platforms the @true is. On limitation of my example is that it assumes that there is just a single module in a file and that has the same name as the file. Would be great if this could be generalized.
[Bug fortran/47495] .mod files: File modification time - Makefile build issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 --- Comment #8 from Ralf Wildenhues rwild at gcc dot gnu.org 2011-01-29 12:20:37 UTC --- (In reply to comment #6) b) A .mod file is read when a USE statement is encountered; the file must exist and is searched for in the include search paths. With any kind of module? Even special-case ones like iso_c_binding? c) If a MODULE is compiled again, but an existing .mod file would not change, the file modification date is not modified. d) Module files (.mod) contain the public procedure interfaces, type declarations and module variables of the module, including those made accessible via USE statements within the module And are not compatible across major/minor/any compiler release/version? I think it would be useful to give an example Makefile file in the manual. Joost's solution (comment 2) seems to work fine, though I am not sure how protable to non-Unix platforms the @true is. The @ specifier is portable make, 'true' is Posix but ':' is better as it is a shell builtin command that does not fork. Pattern rules '%.foo: %.bar' however are a GNU make feature not portable to Posix make, unlike inference rules .bar.foo: which are portable but do not automatically chain (and have a couple of other limitations). Rules of the form a b : c commands ... do *not* designate rules that update a and b at the same time. Rather, they designate two distinct rules, one for a, and one for b, that happen to have the same prerequisites and commands. If you want one rule to update multiple outputs, see http://www.gnu.org/software/automake/manual/html_node/Multiple-Outputs.html (and no, that bit of the manual is *not* autotools-specific, so go somewhere else with any flames please). Unfortunately that chapter still lacks info how to cope well in the presence of 'make -n', this is only fixed in git Automake.
[Bug fortran/47495] .mod files: File modification time - Makefile build issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 --- Comment #9 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-29 12:36:01 UTC --- BTW, there is one thing I would still like to add, but I have not yet tried. gfortran -fsyntax-only test.f90 will generate all .mod files 'defined' by test.f90 This seems like a great way to speedup parallel builds. Right now, make -j X often serializes at '-O3 ' because code generation is slow. Using a two stage compile test.mod: test.f90 gfortran -fsyntax-only test.f90 test.o: test.f90 test.mod gfortran -c -O3 test.f90 could speed things up for large parallel projects since the next file can be compiled (modded ?) as soon as the .mod of the previous one has been generated, there is no need to wait for the .o.
[Bug fortran/47495] .mod files: File modification time - Makefile build issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-29 13:10:32 UTC --- (In reply to comment #8) b) A .mod file is read when a USE statement is encountered; the file must exist and is searched for in the include search paths. With any kind of module? Even special-case ones like iso_c_binding? Well, intrinsic modules are handled differently; some only exist virtually (iso_fortran_env, iso_c_binding) while others exist as file (OpenMP modules); if they exist as file, they are searched for in a target-dependent default directory,* unless -fintrinsic-modules-path is given. (A .mod placed into this directory is regarded as intrinsic module.) Using USE, INTRINSIC :: and USE, NON_INTRINSIC :: one can force which module is searched for; following the Fortran standard, a non_intrinsic module has higher precedence. * On my system: $GCC_PATH/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/finclude And are not compatible across major/minor/any compiler release/version? I tend to forget what is minor in version n.m.l, but 4.x and 4.(x+1) are usually not compatible while 4.x.y and 4.x.(y+1) are (unless a serious wrong-code bug is found, which cannot be fixed otherwise). In principle, the format is such that it should allow modifications (new options skipped over, old files can be read). However, in practice, it turned out that the new features required changes which are not backward compatible. To avoid strange errors, the module version number is bumped if in the new experimental version a change is (potentially) incompatible. I would highly welcome a backward compatible solution, but I do not see any. (A compilation on demand w/o .o generation would be one possibility, but that requires that there is a one-to-one correlation between a module name and a file name.) If you want one rule to update multiple outputs, see http://www.gnu.org/software/automake/manual/html_node/Multiple-Outputs.html That sounds as if a huge number of lines is needed *per file* if one wants to be compatible with POSIX make and avoid compilation cascades. :-(
[Bug fortran/47495] .mod files: File modification time - Makefile build issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 --- Comment #11 from Ralf Wildenhues rwild at gcc dot gnu.org 2011-01-29 13:28:11 UTC --- (In reply to comment #10) If you want one rule to update multiple outputs, see http://www.gnu.org/software/automake/manual/html_node/Multiple-Outputs.html That sounds as if a huge number of lines is needed *per file* if one wants to be compatible with POSIX make and avoid compilation cascades. :-( Which is one of the reasons I would like to see such rules be generated (e.g., by automake or your generator of choice). In order to write a correct rule generator the exact semantics must be known (and of course, we would like to abstract away as much as possible the different semantics from different Fortran compilers).
[Bug fortran/47495] .mod files: File modification time - Makefile build issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 --- Comment #12 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-29 19:31:14 UTC --- (In reply to comment #9) test.mod: test.f90 gfortran -fsyntax-only test.f90 test.o: test.f90 test.mod gfortran -c -O3 test.f90 could speed things up for large parallel projects since the next file can be compiled (modded ?) as soon as the .mod of the previous one has been generated, there is no need to wait for the .o. Actually this seems to work rather well. I have been testing this, and for CP2K on a 48 core server, I get a 2-fold speedup for a fresh build. This really seems something to consider seriously.
[Bug fortran/47495] .mod files: File modification time - Makefile build issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-27 16:11:18 UTC --- For the example, the following works - though it it not robust: The order of the myprogram dependencies matters - and for the same reason doing a make myprogram.o will fail. (Assuming that mymodule.f90 has a change, which is required by myprogram.) myprogram: mymodule.o myprogram.o gfortran -o myprogram myprogram.o mymodule.o mymodule.mod: gfortran -c mymodule.f90 mymodule.o: mymodule.f90 gfortran -c mymodule.f90 myprogram.o: myprogram.f90 mymodule.mod gfortran -c myprogram.f90
[Bug fortran/47495] .mod files: File modification time - Makefile build issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-27 16:52:07 UTC --- Not sure if that solves the issue, but CP2K uses these rules: %.o: %.F $(FC) -c $(FCFLAGS) $ %.mod: %.o @true with these style dependencies: ai_coulomb_test.o ai_coulomb_test.mod : ai_coulomb_test.F cp_common_uses.h cp_error_handling.mod cp_log_handling.mod physcon.mod so faking that .mod is made up to date by having an up to date .o.
[Bug fortran/47495] .mod files: File modification time - Makefile build issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-27 20:26:59 UTC --- Cf. also http://lists.gnu.org/archive/html/help-make/2011-01/msg00102.html
