I asked Claude Code a question:
Q: btw, thinking about a system to keep Fortran MODULE and SUBMODULE information, I imagine an alternative that uses a per-project (software library or executable) database to keep track not only of timestamps for source files but also of “uses”. For instance, for each MODULE X, the database would record each individual USE statement (naming that same MODULE X) in any other source file/program unit/scope. Can you describe how that would cut down on unnecessary recompilations?
A: The key insight is that current build systems operate at the wrong granularity – they track file-level or module-level dependencies, but recompilation necessity is determined at the entity interface level. Here is how a USE-tracking database would help:
WHAT THE DATABASE RECORDS
For every compilation unit that contains a USE statement, it records not just “file B uses module M” but:
For each module definition, it records the interface fingerprint of every public entity.
HOW UNNECESSARY RECOMPILATIONS ARE ELIMINATED
THE PROPAGATION ALGORITHM
When source file F is recompiled and module M is regenerated:
COMPOUNDING BENEFIT ACROSS DEEP DEPENDENCY GRAPHS
In a hierarchy A uses B uses C uses D, a change deep in D affecting only its private implementation would currently force recompilation of C, then B, then A. With the database, the chain stops at D immediately.
RELATION TO EXISTING .MOD FILE APPROACHES
.mod files are binary/opaque and force an all-or-nothing decision. The database reasons at the level of individual entities, handles ONLY-clause filtering, and stores the consumer’s view of the interface rather than just what the module currently exposes.