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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 53DEC7FBFE for ; Sat, 24 Jan 2015 13:57:01 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.213.182; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.213.182 as permitted sender) identity=mailfrom; client-ip=209.85.213.182; receiver=mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ig0-f182.google.com) identity=helo; client-ip=209.85.213.182; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-ig0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiECALOVw1TRVdW2nGdsb2JhbABag1hZBIJ8tAeNYoFfAQmFcQKBCQdDAQEBAQERAQEBAQEGDQkJFC6EDQEBAwESER0BGxIMAwELBgULGh0CAiIBEQEFAQoSBgESEhCHdQEDCQgNsUI+MYsugWuCd4l0ChknAwpUhDsBAQEBBgEBAQEBARYBBQ6PZguCLQwvEYEwBYRCCo1thVaBFTaKfYI3gXMSI4EMCYF9ghQ9MYJCAQEB X-IPAS-Result: AiECALOVw1TRVdW2nGdsb2JhbABag1hZBIJ8tAeNYoFfAQmFcQKBCQdDAQEBAQERAQEBAQEGDQkJFC6EDQEBAwESER0BGxIMAwELBgULGh0CAiIBEQEFAQoSBgESEhCHdQEDCQgNsUI+MYsugWuCd4l0ChknAwpUhDsBAQEBBgEBAQEBARYBBQ6PZguCLQwvEYEwBYRCCo1thVaBFTaKfYI3gXMSI4EMCYF9ghQ9MYJCAQEB X-IronPort-AV: E=Sophos;i="5.09,460,1418079600"; d="scan'208";a="97561867" Received: from mail-ig0-f182.google.com ([209.85.213.182]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 24 Jan 2015 13:57:00 +0100 Received: by mail-ig0-f182.google.com with SMTP id r10so1807426igi.3 for ; Sat, 24 Jan 2015 04:56:58 -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 :content-type; bh=zM8X6vlTk+wiErwHGs0YnuC/xFhstsDQtn2SAYcGsRM=; b=RHNkfOj2tF7ke0PwM0oU1B3dKskMc3YU5Q7GVQDKCI3n1fHuZC5EpLT74jc8zXQ3Jq WE5xyjdrRMr3nlty0pXii1F5CqzggGkieCxZG2Gs+NbPrOo665e/M1MDsqmPS7kNEsux eZYWBMz8PTT6cAt+pseFEqlMCDoHRtLOG9qE2L+sT+Ds8AlOqQoeL6x52jndP9n+9o3M hd3ayaX6k9t77wkBPOQ6cwikMR4VHf9rGb+zI/CVqHrx4tSOHig9vtYTbtzKweyG4mZL L/Ol6x6nhryMfSaViWzyzZGYJTqt+U5cxTUMcpdy4R3liyzIhXSuKMQG0b6ob86MiPLb pXTQ== X-Received: by 10.50.62.110 with SMTP id x14mr7322899igr.2.1422104218541; Sat, 24 Jan 2015 04:56:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.12.133 with HTTP; Sat, 24 Jan 2015 04:56:18 -0800 (PST) In-Reply-To: <0fd907ee06bedeff816160b9e7b9c027@nleyten.com> References: <7bca26c097b73f653bd8bbfa1a07eaa8@nleyten.com> <20150123164111.GA16664@yquem.inria.fr> <0fd907ee06bedeff816160b9e7b9c027@nleyten.com> From: Gabriel Scherer Date: Sat, 24 Jan 2015 13:56:18 +0100 Message-ID: To: Dario Teixeira , caml-list Content-Type: multipart/alternative; boundary=047d7bdc15b8c7e173050d6570df Subject: Re: [Caml-list] Forcing OCamlbuild to compile a file before another --047d7bdc15b8c7e173050d6570df Content-Type: text/plain; charset=UTF-8 Currently there is nothing specific in ocamlbuild to support -no-alias-deps. What the open(Foo) flag does is to to pass the "-open Foo" option to ocamldep, which in turns merely adds Foo to the list of dependencies of the compiled module. My understand of the situation is that it guarantees that project using "-open ..." in their build system will build correctly with ocamlbuild, with two limitations: (1) if you use crazy recursive-but-not-really schemes, you'll get a circular dependencies error (2) if Foo is a list of aliases, it will act as a bottleneck in the dependency graph Any good proposal to change the statu quo will of course be considered -- but I myself have little time to implement new OCamlbuild features -- and I will try to be as reactive on possible bugs (eg. #6755) as possible, as the de-facto maintainer of ocamlbuild. I am not sure what should be done about (1). The almost-recursive scheme was adopted by Jane Street for the extremely specific use-case of migrating an enormous code-base from -pack to -no-alias-deps, but I am not sure it is reasonable to expect it to work for other users (and I doubt it's wise to advertise it as such). In slightly more details: I think the idea of distributing a short-name-giving lambwiki.ml to your users is a good way to emulate -pack without the downsides of -pack, but that you could avoid using the short names in the project itself (that is use Lambda_Parser explicitly rather than Parser). If you did this, the spurious cyclic dependencies disappaear, you can simply use ocamlbuild without any dependency hack, and your users see the short names. On Fri, Jan 23, 2015 at 8:09 PM, Dario Teixeira wrote: > Hi, > > I am not sure. But: why isn't the dependency explicit in >> lambwiki_parser.mly? Doesn't it mention the module name >> "Lambwiki" somewhere? If not, perhaps you could add a >> fake dependency by declaring "module L = LambWiki" at >> the top of lambwiki_parser.mly. Would that help? >> > > I'm still poking at it, but it seems there may be a bug in OCamlbuild, > or at least a difference of opinion. (I am using module aliases and > -no-alias-deps, and some of these waters are uncharted). > > In the tags file, I had declared a tag "open(Lambwiki)" for file > . I assumed this would automatically add a > dependency on lambwiki.ml for lambwiki_parser.mly. > > Now, lambwiki.ml contains only module aliases, for instance: > > module Parser = Lambwiki_parser > module Scanner = Lambwiki_scanner > > To avoid a circular dependency, in myocamlbuild I use the non_dependency > function (part of OCamlbuild's API) to declare that lambwiki.ml does not > in fact depend on Lambwiki_parser and Lambwiki_scanner. > > I wonder if the tooling expects module aliases to produce dependencies > the other way around, ie, Lambwiki_parser depends on Lambwiki but not > vice-versa. This is not clear to me. > > Anyway, adding a dummy dependency as you suggested does the trick for > this particular problem. > > 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 > --047d7bdc15b8c7e173050d6570df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Currently there is nothing specific in ocamlbuil= d to support -no-alias-deps. What the open(Foo) flag does is to to pass the= "-open Foo" option to ocamldep, which in turns merely adds Foo t= o the list of dependencies of the compiled module. My understand of the sit= uation is that it guarantees that project using "-open ..." in th= eir build system will build correctly with ocamlbuild, with two limitations= :
(1) if you use crazy recursive-but-not-really schemes, you'l= l get a circular dependencies error
(2) if Foo is a list of aliase= s, it will act as a bottleneck in the dependency graph

Any good proposal to change the statu quo will of course be conside= red -- but I myself have little time to implement new OCamlbuild features -= - and I will try to be as reactive on possible bugs (eg. #6755) as possible= , as the de-facto maintainer of ocamlbuild.

I am not sure= what should be done about (1). The almost-recursive scheme was adopted by Jane Street for the extremely specific use-case of=20 migrating an enormous code-base from -pack to -no-alias-deps, but I am=20 not sure it is reasonable to expect it to work for other users (and I=20 doubt it's wise to advertise it as such).

In slightly= more details: I think the idea of distributing a short-name-giving lambwiki.ml to your users is a good way to emul= ate -pack without the downsides of -pack, but that you could avoid using th= e short names in the project itself (that is use Lambda_Parser explicitly r= ather than Parser). If you did this, the spurious cyclic dependencies disap= paear, you can simply use ocamlbuild without any dependency hack, and your = users see the short names.
=
On Fri, Jan 23, 2015 at 8:09 PM, Dario Teixe= ira <dario.teixeira@nleyten.com> wrote:
Hi,

I am not sure. But: why isn't the dependency explicit in
lambwiki_parser.mly? Doesn't it mention the module name
"Lambwiki" somewhere? If not, perhaps you could add a
fake dependency by declaring "module L =3D LambWiki" at
the top of lambwiki_parser.mly. Would that help?

 I'm still poking at it, but it seems there may be a bug in OCamlbuild,<= br> or at least a difference of opinion. (I am using module aliases and
-no-alias-deps, and some of these waters are uncharted).

In the tags file, I had declared a tag "open(Lambwiki)" for file<= br> <lambwiki_parser.mly>.=C2=A0 I assumed this would automatically add a=
dependency on lambwiki.ml<= /a> for lambwiki_parser.mly.

Now, lambwiki.ml conta= ins only module aliases, for instance:

module Parser =3D Lambwiki_parser
module Scanner =3D Lambwiki_scanner

To avoid a circular dependency, in myocamlbuild I use the non_dependency
function (part of OCamlbuild's API) to declare that lambwiki.ml does not
in fact depend on Lambwiki_parser and Lambwiki_scanner.

I wonder if the tooling expects module aliases to produce dependencies
the other way around, ie, Lambwiki_parser depends on Lambwiki but not
vice-versa.=C2=A0 This is not clear to me.

Anyway, adding a dummy dependency as you suggested does the trick for
this particular problem.

Kind regards,
Dario Teixeira



--
Caml-list mailing list.=C2=A0 Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners<= /a>
Bug reports: http://caml.inria.fr/bin/caml-bugs

--047d7bdc15b8c7e173050d6570df--