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 nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 53691BB84 for ; Thu, 3 Aug 2006 17:10:54 +0200 (CEST) Received: from [128.93.8.195] (alceste.inria.fr [128.93.8.195]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k73FAr39030003 for ; Thu, 3 Aug 2006 17:10:53 +0200 Message-ID: <44D211FD.4050708@inria.fr> Date: Thu, 03 Aug 2006 17:10:53 +0200 From: Guillaume Rousse User-Agent: Thunderbird 1.5.0.4 (X11/20060618) MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] ocaml support in autotools References: <44CE2C74.4070607@inria.fr> <44CE6483.9070205@tepkom.ru> In-Reply-To: <44CE6483.9070205@tepkom.ru> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 44D211FD.004 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; guillaume:01 guillaume:01 ocaml: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=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 Dmitri Boulytchev 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. 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. 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, ...). -- Guillaume Rousse Projet Estime, INRIA Domaine de Voluceau Rocquencourt - B.P. 105 78153 Le Chesnay Cedex - France