From: Xavier Leroy <xleroy@pauillac.inria.fr>
Message-Id: <199603201006.LAA15404@pauillac.inria.fr>
Subject: Re: Behavior of csldep
To: kgallo@microsoft.com (Kevin Gallo)
Date: Wed, 20 Mar 1996 11:06:33 +0100 (MET)
In-Reply-To: <c=US%a=_%p=msft%l=RED-81-MSG-960318221635Z-13012@red-07-imc.itg.microsoft.com> from "Kevin Gallo" at Mar 18, 96 02:16:35 pm
> When I use csldep to automatically generate dependencies for both
> bytecode and native code versions, the .cmo files are listed as
> depending on .cmi files whereas the .cmx files are listed as depending
> on the .cmx files. Is this the correct behavior and is there a
> workaround?
I'll put this in the FAQ, because it seems to puzzle many users.
.cmx files depend also on .cmx files because these files contain
information for cross-module optimizations. If a compilation unit A
calls a function in unit B, generating code from A.ml looks up
information on the called function in B.cmx.
Hence, if B.cmx changes (e.g. if B.ml is recompiled), A.ml must also
be recompiled, which is obtained by saying that A.cmx depends on
B.cmx.
Not recompiling A may cause its code to become inconsistent with
that of B. This is detected at link-time and causes an error. So, it
would not be safe to remove the dependencies between .cmx files.
On the other hand, it often happens that recompiling a .ml file does
not actually change its .cmx file (if the changes to the .ml file are
small enough), in which case no further recompilation is
needed. Unfortunately, "make" is too dumb to understand that. I have
been unable to express this kind of dependencies in a standard
Makefile. A special-purpose compilation manager is needed to minimize
the amount of recompilation necessary.
- Xavier Leroy