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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id D09037F6CC for ; Wed, 4 Feb 2015 17:45:24 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.223.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.223.182 as permitted sender) identity=mailfrom; client-ip=209.85.223.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ie0-f182.google.com) identity=helo; client-ip=209.85.223.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-ie0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A8AQAlTNJUm7bfVdFag1hZBIJ9r3OPSoVxAoEUB0MBAQEBAREBAQEBAQYLCwkULoQMAQEBAwESEQQZARsSCwEDAQsGBQsNAgIJHQICIgERAQUBChIGExIJB4d2AQMJCA20Kz4xiy6Ba4J3izcKGScDClSFFwEBAQEBBQEBAQEBAQEVAQUOgROOJDMHgmiBQQWESwqOC4VZgRc2jVmBcxIjgQwJhBE9MYJCAQEB X-IPAS-Result: A0A8AQAlTNJUm7bfVdFag1hZBIJ9r3OPSoVxAoEUB0MBAQEBAREBAQEBAQYLCwkULoQMAQEBAwESEQQZARsSCwEDAQsGBQsNAgIJHQICIgERAQUBChIGExIJB4d2AQMJCA20Kz4xiy6Ba4J3izcKGScDClSFFwEBAQEBBQEBAQEBAQEVAQUOgROOJDMHgmiBQQWESwqOC4VZgRc2jVmBcxIjgQwJhBE9MYJCAQEB X-IronPort-AV: E=Sophos;i="5.09,518,1418079600"; d="scan'208";a="120261148" Received: from mail-ie0-f182.google.com ([209.85.223.182]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 04 Feb 2015 17:45:23 +0100 Received: by mail-ie0-f182.google.com with SMTP id ar1so3349511iec.13 for ; Wed, 04 Feb 2015 08:45:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=DCqe4hY7DEKHwWzFxumH7DwmE8ozNoZZlYrOQwGG4D4=; b=Zc4TEuQAjQEzRAJP34pYhTlG7ulghaa67ObkDTDWXVuoI/4T2+2msmWFYExJ5oNUo0 PwNaXwnROflINe6HNUj/4GGu7VwiOs6j6agBzpWfquTi84+eanWIos1npkRT9/v5ZWGb 7NdtE8WHmzE3BJLqJE7giAamLMQu6WPxLQmxnZJNEKRZh5b5vpOajCAEK4LwoTQHMlwt V5lx0gyaNLyTIWVeRmhuq8FePcXK0d236iwclPZO0xVO7/7+PmLFbnQhS9jVqi0Hqrtt UgPHcLUDirVxR3nhvDVk9XcuBBgWxFoawCNje6rB22nOC12XReh8IWgOh/yAkeNgMTJy KsZA== X-Received: by 10.107.18.71 with SMTP id a68mr34691860ioj.89.1423068322282; Wed, 04 Feb 2015 08:45:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.13.195 with HTTP; Wed, 4 Feb 2015 08:44:42 -0800 (PST) In-Reply-To: <1ee7eec964558b9bcb4f0d5650449440@nleyten.com> References: <7bca26c097b73f653bd8bbfa1a07eaa8@nleyten.com> <20150123164111.GA16664@yquem.inria.fr> <0fd907ee06bedeff816160b9e7b9c027@nleyten.com> <6829d3482c94fbe2e22dd1574618e86e@nleyten.com> <5c76729753733a2ccbf1cad96879c312@nleyten.com> <1ee7eec964558b9bcb4f0d5650449440@nleyten.com> From: Gabriel Scherer Date: Wed, 4 Feb 2015 17:44:42 +0100 Message-ID: To: Dario Teixeira Cc: caml users Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] Forcing OCamlbuild to compile a file before another > And, I presume, also remove M from the module's dependency list, right? That's not correct in the general case. Consider for example: bar.ml: ... long_bar.ml: ... foo.mlalias: Bar :=3D Long_bar example.ml: include Bar open Foo include Bar On the contrary, *over*-approximating the dependencies (what happens in the sane situations where M really isn't a dependency, only its long form) should be harmless and is already done by ocamldep anyway (as soon as a you open a module that has submodules and use them, they get listed as extraneous dependencies). > Which leads me to the question: is it feasible to do the postprocessing > in OCamlbuild, or will I have to write an external script that does > the postprocessing and gets invoked by setting Options.ocamldep? You can add new rules in a plugin (eg. one for .mlalias files), and override existing rules by playing with priority levels (which is a kind of dubious business but well...). If you override the ".ml -> .ml.depends" rule (see "ocaml dependencies ml" in ocamlbuild/ocaml_specific.ml, you can replace the current ocamldep invocation by a command that invokes ocamldep and does the preprocessing you want. I suspect that the easier route depends on how you want to specify the logic of which dependencies to remove. If you're happy with listing manually the aliases of your particular project, then just giving them to an external script would probably be easier (sitting inside OCamlbuild don't bring you much because you don't need access to its information) -- note that you can override the ocamldep command from inside myocamlbuild.ml. If you want a somewhat generic mechanism like recognizing .mlalias files, then the ocamlbuild codebase may be of help. On Wed, Feb 4, 2015 at 5:15 PM, Dario Teixeira wrote: > Hi, > >> I thought a bit more about this and here is a plan that seems >> reasonable (I fact-checked it with Pierre Chambart and Beno=C3=AEt Vaugo= n) >> and does not require changing ocamldep. >> >> 1) add a notion of foo.mlalias files with content of the form >> >> M :=3D Foo_M >> Z :=3D Bar_Z >> ... >> >> with a rule .mlalias -> .cmi that generates the .ml and compiles it >> with -no-alias-deps (note that by design it never has any dependency) > > > This seems reasonable. In a sense, modules like foo.ml whose contents > are just a list of aliases are already "special" in a way, and this > convention emphasises that. Moreover, it has an added documentation > advantage: simply by listing mlalias files a newcomer may familiarise > themselves with the module aliases used in a project. > > >> 2) add the following rules in the code that computes dependencies from >> the output of ocamldep: >> if the module depends on Foo (which is the name of an alias >> file) and M, and (M :=3D Bar) is in foo.mlalias, then also add Bar as a >> dependency > > > And, I presume, also remove M from the module's dependency list, right? > > >> - I considered, instead of a .mlalias file with a specific syntax, >> allowing to tag any .ml file as an alias-giving files; that makes the >> system more complex, because the alias-giving files may contain other >> OCaml statements than alias definitions, and thus have some >> dependencies (and we don't want to get in the business of trying to >> guess which modules are just aliases or real dependencies, or having >> to inspect .cmi files after-the-fact to rebuild the aliasing map). The >> downside is that people with an existing -no-alias-deps scheme >> suddenly willing to use ocamlbuild would have to rewrite some stuff >> first. (The other direction can be made automatic by a .mlalias -> >> .ml.inferred rule) > > > Yeah, I see no need to overcomplicate this. > > >> (...) >> - It might be possible to implement this at the plugin level. The >> .mlalias rule could be proposed as a plugin. I'm less confident about >> the dependency-mangling logic, but the idea would be to overload the >> existing ".ml -> .ml.depends" rule to change the .ml.depends result >> (instead of its interpretation by ocamlbuild as I had in mind above). > > > It would be of course nice if all this logic made its way into 4.03 > or 4.02.2 as part of OCamlbuild's builtins. Regardless, from my > perspective of someone who's not familiar with OCamlbuild's code > base and inner workings, I think the most straightforward interim > solution will be along the lines of what I described in my previous > message: write a plugin that postprocesses OCamldep's output. Which > leads me to the question: is it feasible to do the postprocessing > in OCamlbuild, or will I have to write an external script that does > the postprocessing and gets invoked by setting Options.ocamldep? > > > Kind regards, > Dario Teixeira > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs