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 536DBBB84 for ; Fri, 4 Aug 2006 02:41:21 +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 k740fKwL018330 for ; Fri, 4 Aug 2006 02:41:20 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id CAA08476 for ; Fri, 4 Aug 2006 02:41:19 +0200 (MET DST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k740fIo4018295 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 4 Aug 2006 02:41:19 +0200 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G8nkI-0003K2-0T for caml-list@inria.fr; Fri, 04 Aug 2006 02:40:58 +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 02:40:57 +0200 Received: from bga by 195.19.240.21 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 Aug 2006 02:40:57 +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 04:40:55 +0400 Message-ID: <20060804044055.79801082.bga@tepkom.ru> References: <44CE2C74.4070607@inria.fr> <44CE6483.9070205@tepkom.ru> <44D1F265.4040401@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 44D297B0.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 44D297AE.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 guillaume:01 guillaume:01 autoconf:01 fuzzy:01 compiler:01 cpp:01 ocaml:01 camlp:01 ocamllex:01 ocamlyacc:01 ocamlc:01 camlp:01 ocamlc:01 ocamlopt: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 14:56:05 +0200 Guillaume Rousse wrote: > 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. Any examples? =) > 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 As we do right now. > 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. We use OCAMLCDOTOPT for ocamlc.opt and OCAMLOPTDOTOPT for ocamlopt.opt inside AC_PROG_OCAML macro, but they are not available to user yet. It seems like optimized tools work faster (?). What if we will prefer optimized tools by default, but switch to bytecoded if user gives --without-opttools configure argument ? BTW, in my distribution ocamlc is a soft link to ocamlc.opt =). > 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 ? Configure options --enable-native sets OCAML_BUILD_NATIVE --enable-bytecode sets OCAML_BUILD_BYTECODE or similar ? Optimized objects have different file extension (.cmx instead of .cmo), so it is quite easy to define another build rule in Makefile. > 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 ? I guess, we have found a broken findlib on some platform and desided to optionally disable it. > BTW, my global ocaml knwoledge is quite slim, so I may miss details :)