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 A218EBB84 for ; Fri, 4 Aug 2006 07:32:43 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k745Whib023847 for ; Fri, 4 Aug 2006 07:32:43 +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 HAA12178 for ; Fri, 4 Aug 2006 07:32:42 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k745WZub023817 for ; Fri, 4 Aug 2006 07:32:41 +0200 Received: from rosella (ppp30-178.lns1.syd6.internode.on.net [59.167.30.178]) by smtp3.adl2.internode.on.net (8.13.6/8.13.5) with ESMTP id k745WQvR011158; Fri, 4 Aug 2006 15:02:27 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] Re: ocaml support in autotools From: skaller To: Grigory Batalov Cc: caml-list@inria.fr In-Reply-To: <20060804044055.79801082.bga@tepkom.ru> References: <44CE2C74.4070607@inria.fr> <44CE6483.9070205@tepkom.ru> <44D1F265.4040401@inria.fr> <20060804044055.79801082.bga@tepkom.ru> Content-Type: text/plain Date: Fri, 04 Aug 2006 15:32:26 +1000 Message-Id: <1154669546.5926.34.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 44D2DBFB.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 44D2DBF3.003 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 ocaml:01 packagers:01 afaik:01 tarball:01 compiler:01 compilation:01 ocamlc:01 ocamlopt:01 bytecoded:01 compiler:01 ocamlopt:01 bytecode:01 ocamlc:01 bytecode: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 On Fri, 2006-08-04 at 04:40 +0400, Grigory Batalov wrote: BTW: anyone working on this should examine the Debian Ocaml Policy. Sorry no link off hand, ask on debian-ocaml-maint@lists-debian.org At least any macros should work well with Debian packagers requirements, people there have high expertise packaging Ocaml stuff. In particular .. you should note that 'detecting' ocaml libraries is VERY HARD because they're locked to a fixed version of Ocaml: the Ocaml ABI changes with every release (including patches). AFAIK, you simply cannot 'autoconf' check a required library is available: the check will not reveal the version of Ocaml used to build that library .. and it must be built with the version of Ocaml being used for this tarball build or the library is useless. I think what you actually need to do is: (a) find the appropriate Ocaml program (b) find the candidate library (c) check the time stamps on both, and reject the library unless its date is newer than the ocaml program. [My own personal solution to this is (a) never use third party libraries and (b) if I have to, bundle the source code: always build everything from source. For C this would be a nightmare .. for Ocaml it is no problem, the compiler is so fast, and it gives you control of compilation options.. not that there are many] > 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 ? I think you have this procedure: (a) you detect and set variable for support for native compiler: one of: ocamlopt.opt, ocamlopt bytecode compiler: one of: ocamlc.opt, ocamlc interface compiler: one of: ocamlc.opt, ocamlc (this is the same program as bytecode compiler, but it should be managed separately) plus other tools (ocamldep, ocamldoc, findlinb, etc). (b) There at least are 3 models of compilation: native code, bytecode, standalone bytecode (the latter is a single executable file containing the bytecode interpreter and bytecode in one package). The user has several choices: 1. Chose fastest model: native code if possible, otherwise bytecode 2. Chose standalone executable (rare): native code if possible, otherwise standalone bytecode 3. Chose bytecode 4. Chose native code 5. BOTH bytecode and nativecode Developers often want (5) both, but it plays interesting havoc with naive build scripts: the generated programs must have distinct names (libraries and object files already do). My own build system can't handle this :) > > 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. Also because a developer may want to check a system builds without requiring findlib. but the real reason is simpler: some people write Makefiles which require findlib, and will not work without it. Some people write Makefiles that will not work with it. Some people try to support both. -- John Skaller Felix, successor to C++: http://felix.sf.net