From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 1A276BB84 for ; Fri, 4 Aug 2006 03:15:54 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k741FrHi023368 for ; Fri, 4 Aug 2006 03:15:53 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id DAA09134 for ; Fri, 4 Aug 2006 03:15:52 +0200 (MET DST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k741FptD024420 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 4 Aug 2006 03:15:52 +0200 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G8oHl-000570-5p for caml-list@inria.fr; Fri, 04 Aug 2006 03:15:33 +0200 Received: from 195.19.240.21 ([195.19.240.21]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 Aug 2006 03:15:33 +0200 Received: from bga by 195.19.240.21 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 Aug 2006 03:15:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Grigory Batalov Subject: Re: ocaml support in autotools Date: Fri, 4 Aug 2006 05:15:22 +0400 Message-ID: <20060804051522.77ad5fd1.bga@tepkom.ru> References: <44CE2C74.4070607@inria.fr> <44CE6483.9070205@tepkom.ru> <44D211FD.4050708@inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 195.19.240.21 X-Newsreader: Sylpheed version 0.9.10 (GTK+ 1.2.10; i586-alt-linux-gnu) Sender: news X-Miltered: at concorde with ID 44D29FC9.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 44D29FC7.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 guillaume:01 guillaume:01 autoconf:01 ocaml:01 flags:01 flags:01 ocamlc:01 -where:01 lib:01 ocamlfind:01 computed:01 statically:01 run-time:01 lib:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.6 required=5.0 tests=RCVD_BY_IP,RCVD_NUMERIC_HELO autolearn=disabled version=3.0.3 On Thu, 03 Aug 2006 17:10:53 +0200 Guillaume Rousse wrote: > > We are currently using a set of autoconf+automake customized scripts to > > configure and build all of our OCaml projects. The scripts are available > > through http://oops.tepkom.ru/projects/template. > And yet another interface question, this time more related to > AC_CHECK_OCAML_MODULE > > Basically, your implementation tries to discover minimal include flags > needed to make a module available, using various strategies: > - no additional flags > - ocamlfind-based additional flags > - developper defined (through additional macro option), user-defined > (through configure option) and confidure-defined (through running > `ocamlc -where`) flags > > This is not really similar to default AC_CHECK_LIB macro, which just > determine if using all currently available flags, searched library is > available or not. Nor to PKG_CHECK_MODULE (closest ocamlfind equivalent > in C world) that just returns flags computed by pkg-config. Well, we often develop several libraries "in place", without installing, so ../project1 ../project2 cross-referrences are widely used. This is why custom paths in AC_CHECK_OCAML_MODULE appeared. > Knowing if an ocmal module is part of core (thus no need for additional > -I flag), or has ocmalfind support can be statically determined, not at > configure run-time. So, I'd better gives AC_CHECK_OCAML_MODULE a > behaviour more similar to AC_CHECK_LIB, and split ocmalfind logic into a > distinct AC_CHECK_OCAMLFIND_MODULE (or any other better name) that would > just set proper variables. Ok, this looks good. > BTW, the macro seems to be misnamed: what you check for actually is a > set of modules (the second argument), not just a single one. I guess you > want to check for something larger, such as lablgtk, which has several > modules, right ? In that case, I'd rather call it > AC_CHECK_OCAML_MODULES, or something else if there is a dedicated word > in OCaml world to call a set of modules distributed together (library in > C word, distribution in Perl world, package, ...). Sure. At the beginning we had just one module to check =), but later expanded macro to several. AC_CHECK_OCAML_PKG (ocamlfind calls them "packages") should be better. What for camplp4 files, there is several types ("parsers", "printers"), but they all probably should be named "extensions", so AC_CHECK_CAMLP4_EXT would be nice. (Correct me, if I'm wrong.)