From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id EDFFA7EE20 for ; Thu, 15 Nov 2012 22:48:44 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.83,259,1352070000"; d="scan'208";a="162663840" Received: from zmbs4.inria.fr ([128.93.142.17]) by mail4-relais-sop.national.inria.fr with ESMTP; 15 Nov 2012 22:48:44 +0100 Date: Thu, 15 Nov 2012 22:48:44 +0100 (CET) From: Xavier Clerc To: Pierre-Etienne Meunier , O Caml Cc: Xavier Clerc Message-ID: <1201410520.4155202.1353016124507.JavaMail.root@inria.fr> In-Reply-To: <380C67D0-AFB8-471F-84EB-8ED1E92798E7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: [82.216.20.131] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - SAF3 (Mac)/7.2.0_GA_2669) Subject: Re: [Caml-list] About ocamlbuild ----- Mail original ----- > Hi, > > Several ocamlbuild-related questions: > > 1 - Is there a simple reason why ocamlbuild is a tool with plugins > and not a library ? It would be much easier to adapt it to other > contexts than ocaml compiling, and to larger projects. In my > projects, a myocamlbuild.ml file must be written most of the time, > so I do not understand the point. I am afraid I do not grasp the dichotomy you draw between a tool and a library, as ocamlbuild plugins are actually compiled against the ocamlbuild library. Could you elaborate on what you feel wrong with this approach? > Another point I see is that I usually spend a non-negligible part of > my time writing makefiles and myocamlbuild files. Since I must do it > anyway, I'd like to write all that in pure ocaml, doing argument > parsing as I want, adding arguments if I want, and even doing some > configure steps in ocaml before starting to compile anything. Using > output_value to do this (as I did for > http://lama.univ-savoie.fr/~meunier/camlimages for instance) is much > easier than outputing _tags and .mlpack in subdirectories. Well, the first thing to notice is that the ocamlbuild API is not cast in stone, and a tool like camlp4 provides an API allowing to add command-line switches via plugins. However, I have found myself that the question of parameter passing can often be done through tags. As for auxiliary files, it is frequent for me (in personal projects) to create mlpack files from the myocamlbuild file. Indeed, I think that it is even necessary to be really flexible about file addition or deletion (but, of course, this implies to have some sort of "rule" to determine which modules should be packed). > Also, it would be nice to allow it to depend on other modules, even > of some files of the project you are compiling. Examples of uses > include configuration options, versions, etc. I beg to differ with this ability to interleave application code and build code. That being said, nothing prevents you from tweaking your myocamlbuild file at configuration step. > 2 - Also, I do not understand why I get the following message: > > Failure: Included or excluded directories must be implicit (not > "../_build"). > > Is it a technical restriction to avoid copying entire filesystems to > _build if the _tags are ill-written, or is there another reason ? Let me ask you the dual question: why is this restriction causing you some trouble? > 3 - Finally, I find the idea of tags good, for backward compatibility > reasons (you do not have to change your code), but not enough. For > instance, in haskell (and some compilers written in ocaml), you can > add "tags" at the beginning of your files. You would start your > ocaml files with comments such as: > > (* #OPTIONS -rectypes *) Well, I find tags pretty convenient, and do not dislike the comment approach. However, I am pretty sure I do not want the related information to be scattered over multiple locations. Kind regards, Xavier Clerc