Sounds like what fpm is for.
Here are a few more relevant threads and tutorials:
- 49149 – Dependency autogeneration with `-M` rendered useless by requiring .mod files
- Writing Makefiles for Modern Fortran (see section “Automatic dependency generation”)
- Automatically generated dependencies (in Building programs Minibook at fortran-lang.org)
The Fortran Wiki also has a list of tools. I believe some of these tools probably haven’t kept up with language features like block statements and submodules. The Fortran Wiki list highlights one of the problems of Fortran, which is the amount of reinventing the wheel that goes on. If we could join forces and build a robust tool that given a list of source files outputs module dependencies in a chosen format, it could benefit all build systems.
The Ninja build sytem manual contains a short section about Fortran modules, and introduces a “hypothetical fscan tool [that] scans the source files” and writes an output file with the dynamic dependency information.
I guess all of the tools actually follow the same logic, which would be nice to summarize in pseudo-code:
Input: List of Fortran source files
Output: Fortran dependency graph
For File in List of Source Files:
Process(File)...
If we could agree on a good notation for the dependency graph, than any existing or future build tool could use it. The logic fpm uses to resolve dependencies currently is contained in fpm_targets.f90, while the derived type describing source files are defined in fpm_model.f90. The actual parsing is defined in fpm_source_parsing.f90.
It would be great to discuss what are the possible caveats in building a module dependency graph (cyclic dependencies, preprocessing,…) and how to resolve each of them?
Another important question for a scalable tool is how to update the dependency graph given a previous version, and a list of modified files? The author of the tup build system, wrote an interesting document about Build System Rules and Algorithms which I believe are relevant also to the design of fpm.