From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.6.10/8.6.6) id RAA24380 for caml-redistribution; Wed, 20 Mar 1996 17:31:57 +0100 Received: (from xleroy@localhost) by pauillac.inria.fr (8.6.10/8.6.6) id LAA15404; Wed, 20 Mar 1996 11:06:33 +0100 From: Xavier Leroy 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) Cc: caml-list@pauillac.inria.fr In-Reply-To: from "Kevin Gallo" at Mar 18, 96 02:16:35 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: weis > 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