[CMake] fortran, modules and case

[Brad King]

Alan W. Irwin wrote:
> I should also mention that for the simple example I attached to the
> previous
> e-mail the gfortran library build does produce a valid module file called
> hello_module.mod.
> 
> So it appears bug 3984 is just caused by CMake assuming the module file
> name
> is MODULENAME.mod.proxy rather than the correct MODULENAME.mod (where
> MODULENAME is hello_module in the particular case of the simple example I
> gave of bug 3984 in action).
> 
> Does anybody know why cmake appends ".proxy" to the file that it thinks
> will
> satisfy the module dependency?  Perhaps there is a valid reason for
> appending ".proxy" to the real name of the module file, but if that is so
> the CMake developers forgot to take the final step of associating the
> MODULENAME.mod.proxy name with the actual real name of the module file
> produced by fortran compilers.

Years ago I designed a makefile layout that handled everything
correctly.  I had it mostly working in cmLocalMakefileGenerator2 which
was an unreleased intermediate development makefile generator that
preceded cmLocalMakefileGenerator3 (the current makefile generator).
When the implementation was converted to the newer makefile generator by
another developer it was not done quite right and I've never had time to
go back and fix it.

The basic problem for building fortran9x code that uses modules with a
makefile system is that some sources have to be brought up to date
before a make tool even considers the dependencies of other sources.  It
actually requires recursive make calls.  IIRC, the .proxy target is not
meant to ever be a file but just a symbolic make target.  The idea is to
say "I need whomever provides this module to be brought up to date
before make even looks at me" by depending on the .proxy name of the
module.  Any source that provides a module creates a dependency from the
.proxy name to itself.  All these symbolic targets are evaluated to
choose in what order to run make processes to evaluated file-level
dependencies for the actual sources and object files.

The other problem is that the preprocessor must be run in order to check
module-level dependencies since #ifdef can be used to decide whether to
use a module.  Technically this should be done for C and C++ too, but it
would make dependency scanning far slower.  If a few #include lines are
included in the dependency check when they shouldn't in C/C++ it just
adds an extra dependency that doesn't really hurt.  The problem for
Fortran is that the extra dependency can actually break the build.

I'll be glad to help anyone interested in trying to fix any of this get
started.

-Brad