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

[emkemp]

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]

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

[jvgeiger]

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]

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