does anyone know whether dune/ocamlbuild go beyond the timestamp model of
dependency employed by make?
which would be looking at the signature digests of dependent modules and determining
whether to recompile according to change there.
and then beyond that there is the prospect of ruling out at a recompile of a client module on basis of a signature fragment it records (according to its usage of particular components) compared to the newly updated signature of the target module.
does anyone know whether dune/ocamlbuild go beyond the timestamp model of
dependency employed by make?
Both dune and ocamlbuild use content hashes to decide if a target needs to be rebuilt.
and then beyond that there is the prospect of ruling out at a recompile of a client module on basis of a signature fragment it records (according to its usage of particular components) compared to the newly updated signature of the target module.
This would not work due to how separate compilation works in OCaml: implementations record a cryptographic digest of the interfaces of those modules they need to be linked with. Changing a fragment of an interface (even if that particular fragment is not used) requires that one re-compile the clients of that interface.
the fragment I meant is the view of a freshly re-compiled module that a client compilation unit might record that reflects only its usage of said module.
would it be feasible to rely not on a digest but on such a ‘view’ such that it is then the consistency of that view with the module’s signature that decides dependency?
This is already how things work today. Separate compilation means that a compilation unit (.cmo or .cmx) only depends on the interface (.cmi) of the modules it references. If a dependency changes without changing its interface, then the compilation unit does not need to be re-compiled [due to inlining, this statement is not 100% true in native code, but it is a good first-order approximation].
but what constitutes a change in interface at the moment is a digest of a module’s signature. that means. for an extreme example, adding new values/types/exceptions, results in a change of digest even though every compilation unit referencing that digest doesn’t actually depend on those new creations at all.
more commonly, each dependent compilation unit has, in reality, its own subset of dependencies on some module’s signature (it’s view) and unless those dependencies reflect some change there is no need for that compilation unit to be re-compiled.
or so I think!
I’m happy to be shot down if this is a bad idea 
I haven’t thought about the native compilation situation but I think it could work in the byte world.