WIP: Try harder to generate deps for Fortran module files #4452
Conversation
|
Change seems okay to me. I still want to know we have a test that actually tickles the problem in question - that is, fails before, works after. |
|
And indeed - eliminating the incorrect USE statement for the MODULE PROCEDURE is worth doing in any case. |
|
This has been updated a couple of times now to address some issues. Still needs to import the testcase that kicked all this off. |
Tests that module inclusion generates the proper dependencies, so that if the alphabetically-first file uses other modules, thse module files are built first. Signed-off-by: Mats Wichmann <mats@linux.com>
Tests that module inclusion generates the proper dependencies, so that if the alphabetically-first file uses other modules, thse module files are built first. Fix to test framework to support file_fixture() taking a list for dstfile. The docstring says it does, but it didn't do the joining that was done for srcfile. Signed-off-by: Mats Wichmann <mats@linux.com>
mwichmann
force-pushed
the
fortran-mod-deps
branch
from
825b879
to
fe0ae0f
Compare
|
Testcase reported in discussion #4451 is now incorporated. |
|
Recording an issue with this: originally, a ... see where the address of Comments at So: how about if we went back to a combined modules-and-includes cache in suffix = env.subst('$FORTRANMODSUFFIX')
for file in mods_and_includes:
if file.endswith(suffix):
# put in modules
else:
# put in includes |
|
Hmm.. so this line: And/or add a modules attributes to File() since we may(?) need such to handle c++ modules? |
|
I guess we could do either way. Adding a modules might be useful - as you say, C++ may need it, and the D Interface File is basically a module file. Using |
|
Hmmm, not quite sure what the WIndows test failure is. I don't have this setup - it doesn't find gfortran in my case. This looks okay - no errors during build - but then the executable is not there. Notice the built objects use different commandline options than the executable, is it mismatching compiler/linker in this setup, and could that be the problem? |
Looks like it's using MSLINK syntax and LINK=gfortran... |
|
Hmm, it seems I coded the testcase to use gfortran. So it's partly self-inflicted, but still want to explore. |
mwichmann
force-pushed
the
fortran-mod-deps
branch
from
bdaef69
to
3eccedf
Compare
|
After a couple of missteps, this looks better: |
|
After even more digging, I now think this specific problem has to do with the failure to handle No hits. But add the module dir ( Note: this scenario appears to apply to the D scanner as well. That's a non-breaking problem there (failure to find the |
|
Adding a The code in if not node.exists() and not node.is_derived():
print("Could not locate " + str(node.name))
return [], []If you flip the That's nominally correct-looking, but the EDITED: actually the non-duplicating case isn't right either, there's still a path problem in it: it actually needs to be looking in |
|
Attaching the test case for the above (rather than pushing as part of PR, yet), in case someone can spot my errors. |
The Fortran Scanner finds INCLUDE and USE statements, and treats them the
same - no dependency is generated if the indicated file does not exist.
This is correct for include files, but not for module files - at least
ones that are built as part of the project; if no depdency, the .mod file
may not exist before it is used, and if so, scons will abort with an error
("Fatal Error: Cannot open module file 'module1.mod' for reading at (1):
No such file or directory"). With this change, module USE statements are
treated a bit differently. While they are still cached with includes,
the modules are split apart if the cache is found; and the FORTRANMODDIR
when using the file finder to search for files from the scanner.
Rquired fixing test Fortran syntax to use MODULE PROCEDURE in proper
context. Remove use MOD_BAR as you don't use a MODULE PROCEDURE via use
Added new test case: tests that module inclusion generates the proper
dependencies, so that if the alphabetically-first file uses other modules,
thse module files are built first.
Fix to test framework to support file_fixture() taking a list for dstfile.
The docstring says it does, but it didn't do the joining that was done
for srcfile.
Signed-off-by: Mats Wichmann <mats@linux.com>
mwichmann
force-pushed
the
fortran-mod-deps
branch
from
dbc83f7
to
2abc652
Compare
mwichmann
changed the title
…loads gfortran and gnulink, but doesn't explicitly specify the F90 and LINK variables. Let the tools do the right things. This also enables gfortran tool to load a differently named compiler (macports names them gfortran-mp-##)
|
|
I think the only thing we need before merging is a note in FORTRANMODDIR to explain that the path will always be relative to the build root unless it's passed as a Dir() node? |
mwichmann
changed the title
|
marking WIP for the time being. |
The Fortran Scanner finds
INCLUDEandUSEstatements, and treats them the same - no dependency is generated if the indicated file does not exist. This is correct for include files, but not for module files - at least ones that are built as part of the project; if no dependency, the.modfile may not exist before it is used, and if so, SCons will abort with an error (like:Fatal Error: Cannot open module file 'module1.mod' for reading at (1): No such file or directory). With this change, moduleUSEstatements are treated differently: the dependency is created even if the module file does not yet exist.Contributor Checklist:
CHANGES.txt(and read theREADME.rst)