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 A2C367FE36 for ; Sun, 10 Jul 2016 13:33:49 +0200 (CEST) IronPort-PHdr: 9a23:DAsPWBF6MNHiSslYWw33nJ1GYnF86YWxBRYc798ds5kLTJ75oMWwAkXT6L1XgUPTWs2DsrQf2rKQ6PyrAjxIyK3CmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWM5DIfUi/yKRBybrysXNWD14Lsi6vpq9X6WEZhvHKFe7R8LRG7/036l/I9ps9cEJs30QbDuXBSeu5blitCLFOXmAvgtI/rpMYwuwwZgf8q9tZBXKPmZOx4COUAVHV1e1wysejirwXCS0Oj614RVmER2k5NChLZ7Rf2U5L8ti/9nuV40Siee8bxSOZndy6l6vJERQXkwBwbMDoh9WjRjIQkjaRVpzquqgZzhpXIZ4WNMfN4eOXRcIVJFiJ6Qs9NWnkZUcuHZIwVAr9EZL4Aog== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=info@gerd-stolpmann.de; spf=None smtp.mailfrom=info@gerd-stolpmann.de; spf=None smtp.helo=postmaster@mout.kundenserver.de Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.126.134; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.126.134; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.kundenserver.de) identity=helo; client-ip=212.227.126.134; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@mout.kundenserver.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DpAAAiMoJXh4Z+49RdhBR8uxAehXoCgR88EAEBAQEBAQEBEQEBAQgNCQkhL4IyBAESAYITBicuJBA4GVcGEwkSiBkBCa9/b402AQEBAQEBBAEBAQEBFA6FL4oSM4IKC4MHBYgckHyBOQKEUohFiUkEhV+QDzWCKBELgU5sAYl5AQEB X-IPAS-Result: A0DpAAAiMoJXh4Z+49RdhBR8uxAehXoCgR88EAEBAQEBAQEBEQEBAQgNCQkhL4IyBAESAYITBicuJBA4GVcGEwkSiBkBCa9/b402AQEBAQEBBAEBAQEBFA6FL4oSM4IKC4MHBYgckHyBOQKEUohFiUkEhV+QDzWCKBELgU5sAYl5AQEB X-IronPort-AV: E=Sophos;i="5.28,340,1464645600"; d="asc'?scan'208";a="226223545" Received: from mout.kundenserver.de ([212.227.126.134]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2016 13:33:48 +0200 Received: from office1.lan.sumadev.de ([178.4.30.143]) by mrelayeu.kundenserver.de (mreue003) with ESMTPSA (Nemesis) id 0LupZV-1bDrBq2VpR-0106Oo; Sun, 10 Jul 2016 13:33:47 +0200 Received: from [192.168.65.10] (unknown [192.168.65.10]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 06D7ADC05D; Sun, 10 Jul 2016 13:33:46 +0200 (CEST) Message-ID: <1468150422.25014.75.camel@e130.lan.sumadev.de> From: Gerd Stolpmann To: Martin DeMello Cc: "caml-list@inria.fr" Date: Sun, 10 Jul 2016 13:33:42 +0200 In-Reply-To: <1468148606.25014.58.camel@e130.lan.sumadev.de> References: <1468148606.25014.58.camel@e130.lan.sumadev.de> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Uzh2bjZuT3ZK32zWUfHM" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 X-Provags-ID: V03:K0:JLzWCijl/qL3Dss1AHrB4HKxL3sqX32usdGgN62/SNnwQx3J2QY 8edVBwVwxu/B51EhddM1Xb8maosp7Jw+x2LLRgX/+cxpq7MdBWAG6uFiQFXtdIcsG4TBwUY 6XBhrY3SGyH8RYEtTbJ2lKDAYOXFxdS7BTv1/5+nRjGj+uAy3uQaUYtq2IgvE9TEsRrMsG8 7tH5L33rYflbmxhcl+Q5Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:ty9/Bgp8WqU=:Yrp1BgiyVBjTjHDN2OdJzh Z/fugyBELBDG5VvlIHMgw02Ic+Qkbg6fy5mk+Yt4Fh0YYYtn7LZZgbh0BZbcNX9ytmTev/hQh xk3WE4sWrr/zngeJgqg2TG2gaONvVc4Z+YDO6zvqxFMCTycOvXod6HoSl/aMWZdHE/h07IRq0 SylcqPjdB2Oi3qfjH/7PlGZx1TrSypeSMln24nSO8iXFv+a+kwCRa405eHJmWDtGlFBpQUZfx 04zbu10T52apXtdNNUvqa7EC6YIu3tOSKW8LP2tDzjAVOC2U9Bg3bEQKFiObPg+ZGoBZfQ1q4 bEgozRXAWMlpBAVYbvEI4Upl/LNRyW/wiz5dx+H/rJOeUtzC4nX3vdOVzytrboU2a0fHsXeyY wkAMiw8p8enz/sZqhwqOleXFpZJbD9OC1MGdrkF6OZ2RSB5WaG6oE3lvZMy3n6V0iKLjON02j Xdo1Js17HkaW37oFK/YukjuSJ9OZwtqXinQz1sNbJksFCl/ZvmRiSz4CDrXDufDmiEPgg77el QJX2ngE4VGsCOx3ljnFk7+CyKkplhUhmt08Pm7bOMTDJqFyIt5wnxyBbBy5ngt7742zXCl+x8 364COf4dl3Ci7pTq2r4RJzVGpWs2KyZVgKdWGKj4U0wT2tzNe4lgsuyuZ7VKAeUAqTquuhhoT 7s4Rf9JGyGLV7dBi8GdXWrtnqcmg539g/lr9sS7KYD2Qt16QojEjxq1l70I0L09i1Amk= Subject: [Caml-list] Is there an efficient precise ocamldep - Was: why is building ocaml hard? --=-Uzh2bjZuT3ZK32zWUfHM Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Rephrasing this question. Given we wanted to develop an improved version of ocamldep that (a) reads in cmi files from non-project-local directories, and (b) processes all files of the project as a whole, and (c) outputs dependencies precisely. Is there an algorithm that is better than - for all permutations p of the project files: - env :=3D - for all files f of p: - localenv :=3D [] - AST :=3D parse f - interpret the module calculus of the AST, taking env (the toplevel modules) and localenv (the local module scope) into account, with these details: * if there is an unknown module identifier this is an error, and we go on with the next permutation * any definition of a module modifies localenv * the "open" directive is interpreted strictly using env and localenv - no error yet: - env :=3D env + (f -> localenv) (i.e. add the module corresponding to the file to env) - if there is a permutation p that doesn't run into an error, re-run the dependency analyzer for p and output the deps between the (now unambiguously identified) toplevel modules (the keys of env) I think this algorithm is a precise solution to the ocamldep problem (well, I did not take mli files into account, but that shouldn't be too difficult to add). However, it is horribly inefficient. Is there anything better? Gerd Am Sonntag, den 10.07.2016, 13:03 +0200 schrieb Gerd Stolpmann: > Let's have a closer look why it is relatively error-prone to extract the > dependencies. The tool in question is ocamldep. It is fairly dumb in so > far it is only parsing the source code, and then looks at all > module-related constructs (open, include, module, etc.). Because it > never looks into already compiled interfaces and also proceeds file by > file, it may sometimes emit wrong dependency information. For example, > when there is >=20 > open M1 > open M2 >=20 > at the beginning of a file, ocamldep doesn't know whether M2 is another > top-level module, or whether it is a submodule of M1. ocamldep normally > errs on the side of generating too many dependencies, which is then > tried to be corrected by only accepting those deps corresponding to > existing files. In this example, this would mean that a dependency to M2 > is emitted when there is a file M2.ml. Note that this is wrong when M2 > is actually a submodule of M1 AND the file M2.ml exists. >=20 > So how to fix this? In my opinion there are two solutions. You can > either have a more intelligent ocamldep (e.g. one that reads in > non-local cmi files and uses that information and also tries to > interpret all project ml files at once and not file by file - btw, did > anybody check whether there is an algorithm that precisely solves the > problem?). The other solution path is to mark toplevel modules in the > syntax of OCaml (e.g. you'd have to do "open ^M2" is M2 is a toplevel > module). --=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 ------------------------------------------------------------ --=-Uzh2bjZuT3ZK32zWUfHM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJXgjKWAAoJEAaM4b9ZLB5TwOEH/R/1RDRNI7zBMf6+IAaFBBSO VBqtsLaNm5ad1kJ16F1l6CRaYTUkCyLJCNbALEJahseAs9mnptCY+kEND4NvGMHS X3IydWWjIUHyxBt25toxgxW/QixyRgZ7RzUEACW1nDG+eNPzFNoAS8MVFeK5Jrh6 yVxy6O+ndnf1eYEjiKX+jGxY+hUB5CfHU74jS0Tdz6ak/wl0xEziCbproqStnl6Q +4KE1BknUjD7TsgmTtwTWg3GO4LpEhsNtmlKGrPzJ13N47Vq/USHWNVhrWLUe4ZR pxH5zf9s7CDOOu/a80u8rVbHKnRJ0u1PYltuLzQ6VT8GpWjS+s9Ex1hLIYfsQVI= =yHFb -----END PGP SIGNATURE----- --=-Uzh2bjZuT3ZK32zWUfHM--