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 E6E1A7FB5D for ; Sat, 3 Jan 2015 11:52:03 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of r.vermeulen@vu.nl) identity=pra; client-ip=130.37.164.18; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="r.vermeulen@vu.nl"; x-sender="r.vermeulen@vu.nl"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of r.vermeulen@vu.nl designates 130.37.164.18 as permitted sender) identity=mailfrom; client-ip=130.37.164.18; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="r.vermeulen@vu.nl"; x-sender="r.vermeulen@vu.nl"; 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@mailin.vu.nl) identity=helo; client-ip=130.37.164.18; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="r.vermeulen@vu.nl"; x-sender="postmaster@mailin.vu.nl"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEAAPjIp1SCJaQSnGdsb2JhbABcg1hYBIMBwyoGhXUCgQcWAQEBAQERAQEBAQEICwkJFC6EDAEBAQMBIzI0CxgCAhEVAgJHEAYTCYgbCA2pIpN8AQEBAQYBAQEBAQEBARqBIY4jDS0KDIIXOxEdgRMFhSeHF4kJgk6Ed4gTgzmEEW4BgUR+AQEB X-IPAS-Result: AnEAAPjIp1SCJaQSnGdsb2JhbABcg1hYBIMBwyoGhXUCgQcWAQEBAQERAQEBAQEICwkJFC6EDAEBAQMBIzI0CxgCAhEVAgJHEAYTCYgbCA2pIpN8AQEBAQYBAQEBAQEBARqBIY4jDS0KDIIXOxEdgRMFhSeHF4kJgk6Ed4gTgzmEEW4BgUR+AQEB X-IronPort-AV: E=Sophos;i="5.07,689,1413237600"; d="scan'208";a="95206632" Received: from mailin.vu.nl ([130.37.164.18]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 03 Jan 2015 11:52:03 +0100 Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.3.174.1; Sat, 3 Jan 2015 11:52:04 +0100 Received: from [10.0.0.5] (130.37.253.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.3.174.1; Sat, 3 Jan 2015 11:52:01 +0100 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Remco Vermeulen In-Reply-To: <1420222298.12521.72.camel@e130.lan.sumadev.de> Date: Sat, 3 Jan 2015 11:52:01 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: <60E99B69-4F84-4C23-9FD1-3E773C1E7BA5@vu.nl> References: <1088B954-0D62-47D9-B727-2ADE38DD3949@vu.nl> <1420222298.12521.72.camel@e130.lan.sumadev.de> To: X-Mailer: Apple Mail (2.1993) X-Originating-IP: [130.37.253.20] Subject: Re: [Caml-list] ocamldep & compilation units >=20 > On 02 Jan 2015, at 19:11, Gerd Stolpmann wrote: >=20 > 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? >=20 > 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 t= he 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. >=20 > 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 this. >=20 > 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?). >=20 > 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 >=20 > Gerd > --=20 > ------------------------------------------------------------ > 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 > ------------------------------------------------------------