For discussions of all Approximatrix products and related software
You are not logged in. Please login or register.
Approximatrix Forums → User Support → Why touch the modules
During building, *mod files are touched to ensure that dependent files (which USE) the module are re-compiled.
But why not let gfortran look after this? The later versions only update the *mod files and its timestamp when there is a change to the module's interface. It is only in these cases where a re-compilation is necessary.
The use of touch is probably a throw back to earlier versions of gfortran.
David,
The touch steps are present to ensure dependency management and resolution during the build process remains consistent. There are a few problems using a simple Makefile solution when dealing with modern Fortran.
First, if we were just saying that certain Fortran 90+ source files rely on certain module files, we would have no problem except in cases where said module didn't exist, so...
Second, we'd need a build step saying that said missing module relied on the creation of a certain object file being generated. That sounds reasonable; each module from within a given Fortran source file would just rely on the compilation of said source file. However, like you've pointed out, GNU Fortran wouldn't update the resultant module necessarily after compiling if the interface hadn't changed. So conceptually make could fail because, after seeing that a module file was older than the object file associated with the same source file, it would produce an error.
What the touch step does is simply update the module's time stamp to ensure that it is at least as new as its dependent object file to make sure this odd error doesn't occur.
The solution to all of the above would be to either: a) use a bit more rugged make system or b) not use make at all. As for the first option, Simply Fortran uses Open Watcom Make, which is strictly file-based. It does not normally deal with symbolic targets like, perhaps, GNU Make does. Being so file-centric makes the steps described above necessary in a way (or at least historically so in Simply Fortran's case).
The second option would probably be superior (eliminating Simply Fortran's use of make and makefiles entirely). You might notice that the same steps are actually necessary just for checking program syntax. Simply Fortran internally computes dependencies (obviously) and then directs its syntax engine to update syntax checks accordingly when files are modified. This process could be extended to actually perform compilation as well rather than using make.
I see. Its a limitation of Open Watcom's make then. GNU/Make can have multiple targets for a set of dependent files.
I have stopped using make for serious use now.
When I build projects using the command line, I use my own python script to work out the dependencies in my *f90 files and everything just works. Gfortran is one of the few Fortran compilers that properly manages the *mod files so they don't change unless the interface changes. Its always good when I change something about the implementation in a module, then when I build it re-compiles that module and links the program. No unecessary compilation cascades!
Incidently my rule for re-compiling isn't just based on timestamps alone, but also content via an MD5 hash and comparison to a stored database (The database is just a text file with previous md5 hashes for each file in it.) Targets are also dependent on the compiler options used, so if the compiler options change a re-compile occurs (even if no files have changed).
Valid file dependencies are USE-MODULE, INCLUDE (recursively), #INCLUDE (recursively) and SUBMODULES (for when they are eventually supported in the compilers).
It would be really cool to eliminate the use of make in SF in the future (Version 3.0 ?).
g95 is another compiler which change the timestamp of the module file only is the content change. At least for 3 or 4 years!
Yes, both GNU Fortran and g95 both work that way. As I explained, the only reason Simply Fortran works the way it does is its reliance on its make system.
Since this issue has finally become a point of interest, I've gone ahead and made the necessary changes such that Simply Fortran will no longer touch module files. In the latest development version, it will not update module time stamps unless the Fortran compiler has done so itself. The side effect is, of course, the entire dependency tree will not be recompiled if the module interface has not changed.
This change will be available in Simply Fortran 2.8.
Thanks, seems you have been busy.
A subprogram that uses a module doesn't need to be re-compiled if the MOD file has not changed. So this is a good development I think.
You could always have a checkbox on the Make Options form (Always touch module files) and leave it unticked by default. This would give same behaviour as now for those who want the current (2.7) behaviour.
Looking forward to seeing 2.8 with all these new features.
Approximatrix Forums → User Support → Why touch the modules
Powered by PunBB, supported by Informer Technologies, Inc.