Re: [Caml-list] ocamldep, transitive dependencies, build systems, flambda

[Alain Frisch <alain.frisch@lexifi.com>]

Thanks to everyone who commented on my message!

On 05/07/2016 11:17, Nick Chapman wrote:
> There was a further issue we needed to solve to get our scheme working.
> Suppose library A lists library B as a dependency and allows this
> dependence to be exposed in its interface. Clients of library A will
> require access to the .cmi's of library B to be compiled but it seems
> unreasonable to require them to explicitly list library B as a
> dependency. We solve this by automatically running ocamlinfo on the
> public .cmi's of a library to discover additional library deps required
> by clients of the library.

I think this is another instance of the same problem, namely that there 
as "implicit" dependencies that cannot be seen by ocamldep.  It's just 
reduced a bit thanks to the less fine-grained dependency analysis across 
libraries (which we try to avoid in our case).

If we wanted to use the same trick on a per file-basis, one would need 
to inject dynamic dependencies (obtained after compilation), but I don't 
see how to do that with our omake-based build system.

Have you had to change some build rules to account for flambda (I guess 
you must now look for implementation deps in .cmx in addition to 
interface deps in .cmi)?

Here is the solution we you have adopted for now for our experiments 
with flambda.  We apply the same "dependency restriction" for .cmx files 
as we do for .cmi files, namely: whenever the compiler tries to open 
A.cmx when compiling B.ml, it does as if A had been compiled with 
-opaque unless A is an explicit dependency of B.ml (i.e. ocamldep would 
see "A" when analyzing "B.ml").  In effect, this will prevent some 
cross-module optimizations, but we don't see how to do better without 
significantly changing our build strategy.   This solution is similar to 
Hongbo's comment about cross-module inlining in Bucklescript.


Alain