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 42D13BB84 for ; Thu, 3 Aug 2006 14:56:06 +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 k73Cu5bn003695 for ; Thu, 3 Aug 2006 14:56:06 +0200 Message-ID: <44D1F265.4040401@inria.fr> Date: Thu, 03 Aug 2006 14:56:05 +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 44D1F265.000 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 autoconf:01 fuzzy:01 compiler:01 cpp:01 camlp:01 ocamllex:01 ocamlyacc:01 ocamlc:01 camlp:01 ocamlc: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. It seems the most advanced work from all I've been suggested to look at, so I used it as a work base. I'd have some questions however about desirable behaviour for those macros. First, I'd like to keep interfaces and behaviour as close as possible from standard autoconf macros, in particular avoid taking any decision in the macro themselves. Very few of them, for example, throw an error if test fails, they either set variable or takes an action as argument, so as to let the programmer decides what to do. So, I'd like to avoid any use of AC_MSG_ERROR or AC_MSG_WARN in those macros, only AC_MSG_RESULT for printing information. The use of action-if-not-found argument in macro checking for several programs is also unpractical, as its exact semantic is quite fuzzy (what if one of them but not the others are found ?). So, those macros should only set useful variables, without side effect. They are exceptions, tough, for compiler macros-related macros, such as AC_PROG_CC and AC_PROG_CPP. I guess this is because they are unlikely to get used in conditional context. So I guess it would be quite reasonable to make AC_PROG_OCAML fails if no working ocaml is found. And probably also AC_PROG_CAMLP4. But definitevely not for others, and particulary for macros macros looking for ocamllex or ocamlyacc: in C world, lex and yacc-generated sources are generally distributed, to make lex and yacc use non mandatory on installation platforms, and as a consequence, AC_PROG_LEX and AC_PROG_YACC are not fatal macros. So my current opinion is: - have AC_PROG_OCAML fails if ocamlc is not found - have AC_PROG_CAMLP4 fails if ocamlp4 is not found - have all other macros never fail Second, what to do with optimised versions ? It is desirable for the user or the developer to be able to select between optimised and non-optimised version of a given tool ? If not, having a single variable for each tool, silently defined to the optimised version if available and usable, would be the best option. OCAMLC would then correspond to ocamlc.opt or ocamlc If yes, a combination of user options (through AC_ARG_ENABLE), developper options (conditional macros arguments), or distinct variables (OCAMLC and OCAMLC_OPT) would do the trick. Third, I'd like some standard macro to allow the user to select if he wants bytcode compilation, native compilation, or both, the same as you have when using libtool for producing either static or dynamic libraries. Does it makes senses to add those switches to AC_PROG_OCAML, and to define additional variables, such as OCAML_WANT_BYTECODE and OCAML_WANT_NATIVE ? Fourth, in the AC_PROG_FINDLIB, there is a switch allowing the user to disallow the use of ocamlfind, even if present on the system. Why is thie behaviour desirable ? BTW, my global ocaml knwoledge is quite slim, so I may miss details :) -- Guillaume Rousse Projet Estime, INRIA Domaine de Voluceau Rocquencourt - B.P. 105 78153 Le Chesnay Cedex - France