SCons
Fortran module files not handled correctly
This issue was originally created at: 2005-05-30 01:40:45.
This issue was reported by: issues@scons.
issues@scons said at 2005-05-30 01:40:45
When using scons to compile Fortran 90 code with modules, scons does not correctly handle dependencies on module files unless the files are located in the same directory as the corresponding object files.
In particular, the default behavior of most fortran compilers, which is to put the module files in the current working directory, results in all source files containing modules being rebuilt every time scons is run, in a multiple-directory project.
Also, if you set the FORTRANMODDIRPREFIX and FORTRANMODDIR environment variables to cause module files to be placed by the compiler in a different directory, scons apparently does not take any note of this, and expects the module files to be with the object files. The result is again that all source files containing modules --- and any dependent source files --- get fully rebuilt every time scons is run.
Presumably the correct behavior would be that scons kept track of where module files are moved (via the FORTRANMODDIRPREFIX and FORTRANMODDIR variables), and used the files at those paths in determining dependencies.
issues@scons said at 2005-05-30 01:40:45
Converted from SourceForge tracker item 1211215
issues@scons said at 2006-11-02 07:45:46
The original reporter does not specifically note that scons 0.96.x ever detects dependencies between F90 object files and .mod files. It seems scons ignores dependencies it detects by scanning that don't exist at scan time, i.e. those generated as side effects by sibling source files such as .mod files. It also ignores include files that don't exist at scan time.
gregnoel said at 2008-11-30 12:17:12
Bug party triage. David to research and close if it's already been fixed.
gregnoel said at 2010-07-21 16:59:25
Bug party triage. Bump the priority of this issue.
gregnoel said at 2010-09-06 11:40:52
Increase priority so this issue will be reviewed at next bug party.
@mwichmann This is getting repetitive. I think this one should be fixed now too with v4.8.1. See #4177 for some more details.
