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 F09AA7EE20 for ; Thu, 15 Nov 2012 23:36:41 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.83,259,1352070000"; d="scan'208";a="162666502" Received: from zmbs4.inria.fr ([128.93.142.17]) by mail4-relais-sop.national.inria.fr with ESMTP; 15 Nov 2012 23:36:41 +0100 Date: Thu, 15 Nov 2012 23:36:41 +0100 (CET) From: Xavier Clerc To: Edgar Friendly Cc: caml-list@inria.fr, Xavier Clerc Message-ID: <331585634.4160435.1353019001535.JavaMail.root@inria.fr> In-Reply-To: <50A56709.7080105@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 ----- > On 11/15/2012 4:48 PM, Xavier Clerc wrote: > >> 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. > It's exactly this reason that I'm strongly in favor of magic comments > or > pragmas or something in .ml files to do do this kind of thing. > Splitting the data needed to compile a module into two parts: the > module > and a makefile (or _tags or OMakefile or whatever) seems a violation > of > your "multiple locations" policy. I do not follow your line of thought: every information about how to compile is clearly in build files, and not in source code files. If I wonder how the command-line for a given compilation is determined, there is only one place to look. Again, I do not claim that the current state of affairs (everything in build files) is better than a pure pragma-based solution (everything in source files). My objection is about a mixed system where one should have to consult both build and source file in order to know which options are passed to compile a given module. > While I grant that some > compilation > options (whether to compile in debug/profiling/native mode, location > of > external libraries) should not be included in a source file, I'm > strongly in favor of having the build system work out the details of > dependencies (internal to project and external, installed in global > location) and even what camlp4 to run based on the contents of the > file > itself and not elsewhere. To be fair, I should point out that Coq is extracting camlp4 information from source files in order to determine how to treat them. Just a final remark: compared to Haskell, OCaml compilers feature a limited number of command-line switches having an influence on the semantics of a source file(*). I regard this as a pleasant thing, and think this makes the issue at hand quite minor. Kind regards, Xavier Clerc (*) we are only talking about labels, applicative functors, and recursive types