fpm recompiles the whole project when a line is modified

[certik]

On the other hand, cmake only recompiles the given module (if not function interface was changed) and links everything together, so things are much faster.

So this is a big usability deterioration compared to cmake.

[milancurcic]

I was surprised to read this and I haven't used fpm in several weeks so I went back to look. What I observe is actually that if I change one source file (but not changing a procedure interface), fpm rebuilds only the sources that depend on the module(s) in that source file (as opposed to the whole project). This makes sense to me assuming that fpm is only checking if a source file has changed, rather than actually analyzing the source to determine if an interface has changed.

Indeed, doing the same experiment with CMake, sources that depend on that file are not recompiled (if an interface hasn't changed, as you wrote).

[perazz]

To do so, you will have to use submodules as fpm has no embedded Fortran parser, it only checks for used modules to build the dependency tree. I've just checked with the submodules example in example_packages and it actually seems pretty cool: if you only update the submodule, neither the parent module nor any other files depending on it are updated

[certik]

I don't use submodules (I personally do not find them useful, I prefer to just write my functions in a regular module, it's less code and I have all the code in one place).

CMake looks at the mod file, if it changed, it will assume the interface changed and it will recompile. This does not work with all compilers. For example Intel apparently embeds a timestamp in it, so cmake always recompiles. LFortran stores all the code in the mod file, so the file also always changes.

I think that this points to a broader issue: the build system must cooperate with the compiler. For example, LFortran could generate just the interface part, so that cmake could check it if it changed. Possibly it can just output a hash of the interface part, that would be easily to deal with.

[krystophny]

Opened #1289 with an implementation for gfortran.

Approach: gfortran leaves a module's .mod byte-identical when only the
implementation changes and rewrites it on an interface change, so the .mod is a
reliable interface signal. The PR caches a per-object module-interface fingerprint
(a hash of the .mod files an object provides) next to the existing .digest, and
skips recompiling an object whose source and whose dependencies' module interfaces
are all unchanged. The scheduler is untouched: cascade victims stay in the queue
and are pruned at build time, the same shape as ninja's restat. Editing a
procedure body in a used module now recompiles only that module; editing its
interface still recompiles dependents.

It is gated on gfortran, so every other compiler keeps the current cascade and
nothing changes for them.

Remaining path, if this direction is agreed:

• ifx and flang: same mechanism and hash; their .mod is also stable across body
  edits, so each is one allowlist entry. flang already exposes an FNV-1a interface
  checksum in its .mod header.
• nvfortran: same, after stripping an embedded date/time string from the .mod
  before hashing.
• lfortran: it inlines across modules by default, so a body change does require
  rebuilding dependents there; with --separate-compilation it uses the symbol
  model where skipping is safe, and the remaining piece is a stable interface hash
  (the mod format already reserves an export-ASR slot for this).

Does the approach and staging make sense?