From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 1B243BC0A for ; Thu, 16 Nov 2006 15:20:46 +0100 (CET) Received: from [128.93.8.195] (alceste.inria.fr [128.93.8.195]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id kAGEKhLH027166; Thu, 16 Nov 2006 15:20:43 +0100 Message-ID: <455C73BA.1030803@inria.fr> Date: Thu, 16 Nov 2006 15:20:42 +0100 From: Guillaume Rousse User-Agent: Thunderbird 1.5.0.8 (X11/20061109) MIME-Version: 1.0 To: autoconf@gnu.org, caml-list@yquem.inria.fr Subject: managing ocaml dependencies X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 455C73BB.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; guillaume:01 guillaume:01 ocaml:01 dependencies:01 autoconf:01 ocaml:01 dependencies:01 ocamldep:01 makefile:01 ocamldep:01 mli:01 unix's:01 makefile:01 unix's:01 unix:01 I'm trying to use autoconf for ocaml project, and I have troubles with managing dependencies. They are generated through a specific program, ocamldep, that basically output makefile rules, so as to be used this way: .depend: $(OCAMLDEP) *.ml *.mli > .depend include .depend They are two different strategies here, either generate them on maintainer host and ship them in the distribution, either generate them on user's host. The first seems safe, excepted when you have conditional build options: if the user has not the same setup as the maintainer host, there might be inconsistencies. I also saw some comments in autotools description than this strategy was also considered insecure for other languages. The second strategy, however, heavily relies on make implementation. Whereas GNU make happily generate .depend file on the fly with previous snippet, some other implementations don't, such as Digital Unix's one (and potentially others). Make: Cannot open ../.depend. Stop. I also discovered than GNU make use current directory to resolve path of included files, even when the inclusion directive is found in an included makefile, whereas Digital Unix's one consider the directory containing the makefile containing the inclusion directive instead. Given the following setup: |-- Makefile.rules `-- a `-- Makefile If the inclusion directive is given in top level Makefile.rules, itself included in lower level a/Makefile, GNU make resolve the .depend file in a directory, whereas Digital Unix resolve it in top-level directory. Finally, it seems the safest strategy would be to use configure to produce those .depend file, or is there any other possibility ?