From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 8E6617FB5D for ; Sat, 3 Jan 2015 12:33:36 +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.214.175; 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.214.175 as permitted sender) identity=mailfrom; client-ip=209.85.214.175; 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-ob0-f175.google.com) identity=helo; client-ip=209.85.214.175; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-ob0-f175.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsAAIXSp1TRVdavm2dsb2JhbABcg1hYBIMBs3GGE4dJgV8BCYVxAoEABxYBAQEBAREBAQEBAQYLCwkULoQMAQEBAwESER0BFAcSCwEDDAYDAgsDCg0IFQICIgERAQUBChIGEwkJEId1AQMJCA2MQ5BLPjGLLoFrgneKOgoZJwMKVIM3AQEBAQEBAQECAQEBAQEBAQEUAQUOj0MiBAcKgiM7EYEwBYQtBnSHF4UWg3OBQYENMIxagW8SI4EMCYQRPTEBgkIBAQE X-IPAS-Result: AnsAAIXSp1TRVdavm2dsb2JhbABcg1hYBIMBs3GGE4dJgV8BCYVxAoEABxYBAQEBAREBAQEBAQYLCwkULoQMAQEBAwESER0BFAcSCwEDDAYDAgsDCg0IFQICIgERAQUBChIGEwkJEId1AQMJCA2MQ5BLPjGLLoFrgneKOgoZJwMKVIM3AQEBAQEBAQECAQEBAQEBAQEUAQUOj0MiBAcKgiM7EYEwBYQtBnSHF4UWg3OBQYENMIxagW8SI4EMCYQRPTEBgkIBAQE X-IronPort-AV: E=Sophos;i="5.07,689,1413237600"; d="scan'208";a="95208826" Received: from mail-ob0-f175.google.com ([209.85.214.175]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 03 Jan 2015 12:33:35 +0100 Received: by mail-ob0-f175.google.com with SMTP id wp4so55729853obc.6 for ; Sat, 03 Jan 2015 03:33:33 -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; bh=Qn9+HRipgd3MWttRqODbr6/eQMOARfCOqnwHh2Q6TwQ=; b=lx3GWkATjM4EEUahM57dtYysHEyK4SO8CEZ9erHpvQ9njo34Y1RI41YzBgrPmPPBJd YN77T1HxZcrcC/NP1hVPhwJ1Arn5UmPzBNtbzbYcoJAp2V2k932De3oz6OBXH95tdbty LbagUrdQ+jiafqdps9f8DhLroZU84sjpuQQa/9PPXLmkEV5Xb/FIjQFk1mmgs4I29E63 0jCj1JzObo0SnYXQ5jtYY/yEiyQQ2M45hdzDN23d1OvLEmdxu1uf9+3X116U1v07KSTO 9JKa/rd5KKjikISeCqgUZ/ZSAdoX9gjWF1jh+E1h2kNsKT4TOs743wdi3Cnkw5uH38eE PeHw== X-Received: by 10.60.131.202 with SMTP id oo10mr46973892oeb.72.1420284813431; Sat, 03 Jan 2015 03:33:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.5.171 with HTTP; Sat, 3 Jan 2015 03:32:53 -0800 (PST) In-Reply-To: <60E99B69-4F84-4C23-9FD1-3E773C1E7BA5@vu.nl> References: <1088B954-0D62-47D9-B727-2ADE38DD3949@vu.nl> <1420222298.12521.72.camel@e130.lan.sumadev.de> <60E99B69-4F84-4C23-9FD1-3E773C1E7BA5@vu.nl> From: Gabriel Scherer Date: Sat, 3 Jan 2015 12:32:53 +0100 Message-ID: To: Remco Vermeulen Cc: caml users Content-Type: multipart/alternative; boundary=047d7b47214ec8d782050bbdd377 Subject: Re: [Caml-list] ocamldep & compilation units --047d7b47214ec8d782050bbdd377 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ocamldep is approximative by design (providing a correct list of dependencies requires interleaving type-checking and dependency computations, a very different *compiler* design that would require an important amount of work). The easiest way out in the current state of things is to have an option in build systems to remove spurious dependencies by hand (they're quite rare in practice). ocamlbuild for example has a (non_dependency "baz" "BAR") that you would use in your situation. If Omake lacks such a capability, I think the best step forward would be to add it (instead of trying to come up with different heuristics than "ocamldep -modules"). On Sat, Jan 3, 2015 at 11:52 AM, Remco Vermeulen wrote: > > > > On 02 Jan 2015, at 19:11, Gerd Stolpmann wrote: > > > > Am Freitag, den 02.01.2015, 15:03 +0100 schrieb Remco Vermeulen: > >> So my question is. is BAR in the above example correctly identified as > a compilation unit by ocamldep? > > > > The syntax doesn't allow an unambiguous identification, so ocamldep > > needs to take into account that BAR is a compilation unit. It doesn't > > follow "open" when doing this, and I guess this is the point that > > confuses you. > What confused me is that the documentation says ocamldep -modules returns > the module names of compilation units > referenced in the source file, and then includes local modules when the > =E2=80=9Cparent=E2=80=9D module is implicitly qualified through open. > When the local module is referenced explicitly (i.e, fully qualified), it > is not included, which is inconsistent. > > > > The problem is that "ocamldep -modules" by definition can only analyze a > > single module. The output is imprecise, however, and possible > > inter-module effects are not taken into account (among other things). A > > precise output would list BAR with the exception that it might be > > shadowed by Foo. > Perhaps a note should be added to the documentation of ocamldep about thi= s. > > > > But imagine now we had the information with this degree of detail. As > > omake wants to figure out the dependencies it would have to solve a > > puzzle. In your case it is easily to solve, but in practice there are > > often several "open" directives, and in this case you don't even know > > whether "open Foo" opens a compilation unit. I am not sure whether a > > well-performing algorithm even exists (did anybody tackle this > > problem?). > > > > The workaround is to use naming schemes that allow you to clearly > > distinguish between local modules and compilation unit (e.g. all your > > local modules have 1-3 characters, and all compilation units have longer > > names). > This is not really an option, since this happens in an 3rd party library. > It seems that patching the omake ocaml scanner, to not rely on the > -modules option, > seems to be the way to go as this is not trivial to handle in ocamldep. > > Thanks for your clarification! > > Cheers, > Remco > > > > > Gerd > > -- > > ------------------------------------------------------------ > > Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de > > My OCaml site: http://www.camlcity.org > > Contact details: http://www.camlcity.org/contact.html > > Company homepage: http://www.gerd-stolpmann.de > > ------------------------------------------------------------ > > -- > 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 > --047d7b47214ec8d782050bbdd377 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
ocamldep is approximative by design (providing a correct l= ist of dependencies requires interleaving type-checking and dependency comp= utations, a very different *compiler* design that would require an importan= t amount of work). The easiest way out in the current state of things is to= have an option in build systems to remove spurious dependencies by hand (t= hey're quite rare in practice). ocamlbuild for example has a (non_depen= dency "baz" "BAR") that you would use in your situation= . If Omake lacks such a capability, I think the best step forward would be = to add it (instead of trying to come up with different heuristics than &quo= t;ocamldep -modules").

On Sat, Jan 3, 2015 at 11:52 AM, Remco Vermeulen <r.ve= rmeulen@vu.nl> wrote:
>
> On 02 Jan 2015, at 19:11, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
>
> Am Freitag, den 02.01.2015, 15:03 +0100 schrieb Remco Vermeulen:
>> So my question is. is BAR in the above example correctly identifie= d as a compilation unit by ocamldep?
>
> The syntax doesn't allow an unambiguous identification, so ocamlde= p
> needs to take into account that BAR is a compilation unit. It doesn= 9;t
> follow "open" when doing this, and I guess this is the point= that
> confuses you.
What confused me is that the documentation says ocamldep -modules re= turns the module names of compilation units
referenced in the source file, and then includes local modules when the =E2= =80=9Cparent=E2=80=9D module is implicitly qualified through open.
When the local module is referenced explicitly (i.e, fully qualified), it i= s not included, which is inconsistent.
>
> The problem is that "ocamldep -modules" by definition can on= ly analyze a
> single module. The output is imprecise, however, and possible
> inter-module effects are not taken into account (among other things). = A
> precise output would list BAR with the exception that it might be
> shadowed by Foo.
Perhaps a note should be added to the documentation of ocamldep abou= t this.
>
> But imagine now we had the information with this degree of detail. As<= br> > omake wants to figure out the dependencies it would have to solve a
> puzzle. In your case it is easily to solve, but in practice there are<= br> > often several "open" directives, and in this case you don= 9;t even know
> whether "open Foo" opens a compilation unit. I am not sure w= hether a
> well-performing algorithm even exists (did anybody tackle this
> problem?).
>
> The workaround is to use naming schemes that allow you to clearly
> distinguish between local modules and compilation unit (e.g. all your<= br> > local modules have 1-3 characters, and all compilation units have long= er
> names).
This is not really an option, since this happens in an 3rd party lib= rary.
It seems that patching the omake ocaml scanner, to not rely on the -modules= option,
seems to be the way to go as this is not trivial to handle in ocamldep.

Thanks for your clarification!

Cheers,
Remco

>
> Gerd
> --
> ------------------------------------------------------------
> Gerd Stolpmann, Darmstadt, Germany=C2=A0 =C2=A0 gerd@gerd-stolpmann.de
> My OCaml site:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.camlcity.org
> Contact details:=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.camlcity.org/contact.ht= ml
> Company homepage:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.gerd-stolpmann.de
> ------------------------------------------------------------

--
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
Bug reports: http://caml.inria.fr/bin/caml-bugs
--047d7b47214ec8d782050bbdd377--