From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 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 BE770BB83 for ; Fri, 8 Sep 2006 16:52:07 +0200 (CEST) Received: from [128.93.8.195] (alceste.inria.fr [128.93.8.195]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k88Eq7qA032562 for ; Fri, 8 Sep 2006 16:52:07 +0200 Message-ID: <45018397.5080806@inria.fr> Date: Fri, 08 Sep 2006 16:52:07 +0200 From: Guillaume Rousse User-Agent: Thunderbird 1.5.0.5 (X11/20060804) MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: ocaml support in autotools References: <44CE2C74.4070607@inria.fr> <44CE6483.9070205@tepkom.ru> <44D1F265.4040401@inria.fr> <20060804044055.79801082.bga@tepkom.ru> <1154669546.5926.34.camel@rosella.wigram> In-Reply-To: <1154669546.5926.34.camel@rosella.wigram> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 45018397.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; guillaume:01 guillaume:01 ocaml:01 factorize:01 packagers:01 ocaml:01 versioned:01 afaik:01 tarball:01 higher-level:01 compiler:01 compilation:01 ocamlc:01 ocamlopt:01 bytecoded:01 I'm trying to factorize answers here. skaller wrote: > At least any macros should work well with Debian packagers > requirements, people there have high expertise packaging Ocaml > stuff. Indeed. > 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). Right, I introduced an automatic versioned dependency in mandriva rpm for this reason. > 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. Right, and it also support my point on distinguishing between retrieving information, and testing it is accurate. By why not try to compile and link for (c) instead of trusting timestamps ? This is an higher-level check, and closer from the actual problem moreover. > [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. Are you trying to compete with Java and PHP developper here ? Using private code copies may make your (programmer) life easier, but just make distribution package maintainers works more complex, as they have to remove them and make sure your code build with system version. That's a wrong solution to a real problem. > 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 ? It is precisely my point: is so much flexibility desirable ? > 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) I don't understand the interest of that specific point. > plus other tools (ocamldep, ocamldoc, findlinb, etc). This is the simplest model, which is also the more robust. I have some proposal that seems quite simple to achieve: - for each of those alternative, have AC_PROG_OCAML export two variables, FOO and FOO_OPT - by default, FOO would point to the same value as FOO_OPT if available - a user switch would prevent this behaviour So, the developper could enforce the use of only optimised versions, or let the choice to the user with a correct default. Does it sounds good ? > (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 :) Ouch, it hurts... We're just dealing with autoconf macros here (no automake support yet), meaning developer still has to write the corresponding Makefile. Providing users switches in those macros force the developper to handle them. So, I'd rather keep uneeded complexity out, at least for the moment. Allowing 3, 4 & 5 is possible with the following scheme, based on AM_PROG_LIBTOOL: - by default, AC_PROG_OCAML provides --enable-native and --enable-bytecode switches, defaulting to true - AC_DISABLE_OCMAL_NATIVE turns off the default value for --enable-native - AC_DISABLE_OCMAL_BYTECODE turns off the default value for --enable-bytecode Those switches just set OCAML_BUILD_NATIVE and OCAML_BUILD_BYTECODE variables. >>> 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. If there is an explicit list of platform/findlib versions known to be broken, or a typical way to diagnose such problems, this ought to be managed directly in the macro itself, with some kind of error message, not through a user switch. > 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. But you don't need an explicit option for this: if you really want to be findlib-independant, test with findlib installed and without findlib installed. My point is: don't put too much personal preferences in those shared macros, especially as someone else will have to maintain them. They should only bring a minimal number of consensual primitives, upon wich developers may design their own build script that fit their own taste. If you look at pkg-config, for instance, there is no AC_PROG_PKCONFIG macro that automatically bring you a switch to disable its use. However, PKG_CHECK_MODULE allows you to override pkg-config results automatically each time you use it for a given library. -- Guillaume Rousse Projet Estime, INRIA Domaine de Voluceau Rocquencourt - B.P. 105 78153 Le Chesnay Cedex - France