[CMake] Fortran 90 module output directories, dependency analysis

[Kelly Thompson]

On Tuesday, June 01, 2010 at 11:48 AM, Brad King wrote:

> You can delete the object file the provides the module.
> 
> > Perhaps that scenario where
> > module files are deleted independent of the object/libraries is
> > artificial, but it's not really correct for the build to break if they
> > are deleted.
> 
> The problem is that the build system doesn't actually point directly
> at the .mod files so it doesn't know when they are missing.  I don't
> remember all details off the top of my head, but there are very good
> reasons that the build system doesn't see .mod files directly.
> 
> Fixing this would require some kind of side-effect map.  At the start
> of each build the object file providing a missing module would need
> to be deleted.  We already have something similar for custom commands
> with multiple outputs, but a major distinction is that CMake knows
> what files are paired together at generation time.  Object->module
> mapping is not known until build time (during dependency scanning).

By using try_compile, you can determine how your FORTRAN compiler generates
modules files (i.e.: the object->module mapping).  Once this mapping is
determined, you can predict all of the module file names before compilation
begins.  I use this technique in my project to generate a list of expected
module files that should be 'installed.'  

I suppose that you could use this generated list of module files along with
CMake's add_custom_command, add_custom_target and/or add_dependencies
commands to force the build system to recheck the module files on each build
invocation.  That sounds like a lot of work.  For my small project I prefer
using 'make clean; make all' in place of tracking all of the module
dependencies.

-kt