# I come to bury .mod files not to praise them **URL:** \ **Category:** Advocacy\ **Created:** [September 25, 2026, 6:33pm UTC](https://fortran-lang.discourse.group/t/i-come-to-bury-mod-files-not-to-praise-them/11128 "2026-09-25T18:33:29Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![themos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/themos/32/521_2.png) [@themos](https://fortran-lang.discourse.group/u/themos)\ **Post date:** [September 25, 2026, 6:33pm UTC](https://fortran-lang.discourse.group/t/i-come-to-bury-mod-files-not-to-praise-them/11128/1 "2026-09-25T18:33:30Z")
TLDR:We have lived with .mod files for 35 years at least. That’s enough. It is time to give them up. Efficient recompilation requires fine-grained analysis. What can replace them? And what other wins can an alternative enable? To kick off the discussion, I want to present a half-baked idea: the lazy compiler leveraging a database. The lazy compiler, given a filename that is recognised as Source (a “load”) proceeds to complete the stages up to semantic analysis. If valid, it stores information about the canonicalised lexed source, the program units, the scopes and symbol tables, the module USE dependencies, etc in the database. Once it reads the source, what happens to the file containing the source is immaterial (e.g. it can be piped in). The context is a user-selected Fortran identifier (e.g. MAIN\_WEATHER or LIB\_MPI). A duplicated global identifier is identified as an error by consulting the current database (with current compilers you might get a linker error, or nonsensical/unintended results). A special option on the compiler enables the next stage, code generation from the digested source in the database. First, the database context is consulted for existing compilations of the global identifiers. The first time, the database has none. The compiler walks the dependency chain already in the context and determines an order of compilation (including parallel jobs) and executes them. A subsequent time, after a “load” of new versions of some global identifier, a program unit (or possibly a more fine-grained entity) can be determined to not be affected by the change, and the last recorded object code is marked as valid without new code generation needed. The essence is that the compiler is in charge of what needs to be recompiled and when, not the build system. Shall we build it? _The evil that men do lives after them_ ---
**Author:** ![jorgeg](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jorgeg/32/6835_2.png) [@jorgeg](https://fortran-lang.discourse.group/u/jorgeg)\ **Post date:** [September 25, 2026, 10:45pm UTC](https://fortran-lang.discourse.group/t/i-come-to-bury-mod-files-not-to-praise-them/11128/2 "2026-09-25T22:45:24Z")
After handling \*.h files in C/C++ and paths using `#include "lib/core/my_lib"` and `#include ` and the same way of doing things in Python I feel that `.mod` files are the lesser of evils. With CMake you can very nicely say where they go and installing them is simple, you can always just put everything into your `install_prefix/modules` or something like that. CMake also gives you a good way to control that and with the FPM it is super easy. What kind of workflows/scenarios are you having where the mod files annoy you? I am working with fairly large codebases and using reusable libraries across them and `.mod` files have not been a concern at all…I am curious. Compiling is also simple-ish right, the compiler knows what it needs to recompile if you do a change. In C++ you have the same problem when you modify the one header file that is everywhere and god it is awful. In this day an age, unless you’re building on a microwave you can do at least `make -j4` and make things go really fast.