search

NASA-LIS / LISF

Land Information System Framework
Apache License 2.0
114 stars 153 forks source link

LIS build system does not include non-module Fortran files in dependencies #636

Open emkemp opened 3 years ago

emkemp commented 3 years ago

The current LIS build system only adds Fortran modules and C headers to the autogenerated dependency files. For example, timeinterp_PALSmetdata.d contains:

timeinterp_PALSmetdata.o timeinterp_PALSmetdata.d : timeinterp_PALSmetdata.F90 timeinterp_PALSmetdata.o : PALSmetdata_forcingMod.o timeinterp_PALSmetdata.o : LIS_constantsMod.o timeinterp_PALSmetdata.o : LIS_misc.h timeinterp_PALSmetdata.o : LIS_timeMgrMod.o timeinterp_PALSmetdata.o : LIS_logMod.o timeinterp_PALSmetdata.o : LIS_coreMod.o timeinterp_PALSmetdata.o : LIS_metforcingMod.o timeinterp_PALSmetdata.o : LIS_FORC_AttributesMod.o

This should also include zterp.o, which is created from a standalone Fortran source file (no module).

This interferes with the "strict check" (-3) build option, where the Intel compiler automatically generates Fortran interfaces so subroutine and function argument lists can be changed. Because of the missing dependency, the build system may not compile the true dependencies in the correct order, and the interface is not generated in time for checking.

This is only an issue for the "strict check" option.

emkemp commented 3 years ago

The longer term/easier solution may be to migrate all standalone Fortran files into modules.

jvgeiger commented 3 years ago

The makedep.py tool searches only for use, include, and #include statements. It does not try to parse the source code to find function or subroutine calls.

I agree that the most straight forward solution is to migrate these bare subroutines into modules.

emkemp commented 2 months ago

We'll get to this. Someday....