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 192E37FE36 for ; Mon, 11 Jul 2016 12:36:49 +0200 (CEST) IronPort-PHdr: 9a23:/gbNKBC5xG9Gpc8bp8uMUyQJP3N1i/DPJgcQr6AfoPdwSP7zp8bcNUDSrc9gkEXOFd2CrakV06yN7uu6BiQp2tWoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09fr2zQd+KyZ/qnLrts7ToICxwzAKnZr1zKBjk5S7wjeIxxbVYF6Aq1xHSqWFJcekFjUlhJFaUggqurpzopM0r221qtvkg789NV7nhN+R9FOQATWduD2dgytdquZjZTADHzHwBSC1CnABFDwXf7Rq8VJDsqAP+v+l00iCce8v7UeZndy6l6vJERQXkwBwbMDoh9WjRjIQkjaRVpzquqgZzhpXIZ4WNMfN4eOXRcIVJFiJ6Qs9NWnkZUcuHZIwVAr9EZL4Aog== Authentication-Results: mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.17.24; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.17.24; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.kundenserver.de) identity=helo; client-ip=212.227.17.24; receiver=mail3-smtp-sop.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: A0AjAQDzdYNXhxgR49RchBR8uReBeh6FegKBJzkTAQEBAQEBAQERAQEBCA0JCSEvgjIEARIBghMBBQxJJBALGC5XBhMJEogZAQm/CAEBAQEBAQQBAQEBARQOhS+FRYRNgj0LgwcFiByQfIE5AosEghOJSQSFX5APIAKCOwEQC4FObAGJPgEBAQ X-IPAS-Result: A0AjAQDzdYNXhxgR49RchBR8uReBeh6FegKBJzkTAQEBAQEBAQERAQEBCA0JCSEvgjIEARIBghMBBQxJJBALGC5XBhMJEogZAQm/CAEBAQEBAQQBAQEBARQOhS+FRYRNgj0LgwcFiByQfIE5AosEghOJSQSFX5APIAKCOwEQC4FObAGJPgEBAQ X-IronPort-AV: E=Sophos;i="5.28,346,1464645600"; d="asc'?scan'208";a="184489801" Received: from mout.kundenserver.de ([212.227.17.24]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2016 12:36:33 +0200 Received: from office1.lan.sumadev.de ([88.68.67.213]) by mrelayeu.kundenserver.de (mreue103) with ESMTPSA (Nemesis) id 0MI8Ug-1bPJC53Gn8-003yYo; Mon, 11 Jul 2016 12:36:31 +0200 Received: from [192.168.65.10] (unknown [192.168.65.10]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id CD49FDC05D; Mon, 11 Jul 2016 12:36:30 +0200 (CEST) Message-ID: <1468233385.25014.97.camel@e130.lan.sumadev.de> From: Gerd Stolpmann To: =?ISO-8859-1?Q?Fr=E9d=E9ric?= Bour Cc: caml-list@inria.fr Date: Mon, 11 Jul 2016 12:36:25 +0200 In-Reply-To: References: <1468148606.25014.58.camel@e130.lan.sumadev.de> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-3NwyqUNIw2jEvaSgoeD5" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 X-Provags-ID: V03:K0:2NZ1ve4XWZtgVq83TGaXlDVkWD6BmvX5jcj+rJHaAyIjHlGgkI8 B3xXdFLMOcPYUokXuOyFCPSdbDBv+ZIJgb45Al3sk+bDMIHTF2HTS73l9XlGAmGMpHudH4X APowBA7IiXbuJpXQz/vseHDKnHsAH+zFGdFmg90BquVbpVuM0tR/hjHN07mzTBxSjRay0Pz b/dMCvcv457LBlMOaw6OA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Bp9EwoXGJCc=:TJvQjVABc+w6jWyIuqR7JS YajQ2S3Lcvrd3L+vh9d31yF+2nBsvEwd6biAlLvT6luRr8bVK6YNps+Xk/k9SF+Z+AuT7RhNW I6/mhnRw6e/hFcb8pw5Gp75uTNS5BCAvsZOh4kNzszIMf9v+3gdjH+24tGRPtlnyLsN33yL93 v5h6Eneq48EjYK+aAbIvg6zONTJ6VMLwwALmknj+5y6+CYkFU6N/6TnnTd2uAY71TG+f6gVQf VPA3Pr3fzRnWn1RCPC48szZt+N0H27cZ8Qujv6tUo0GRgtYBVmkjx0q/rIABhb2sTVxMGtfq8 HbEEOgcQm7M46tdXsONr7I7HB0gfx9MceD1dGtPDtFdCo64+Q1rqmUym988oCyZDKESZDKWhH 9NVA1jRe7xAH6/A/d+OY+6qTFMaW6HhttFkmFspuIYqP/qg9dTomaLEvq9h294YYSP8p64Ma+ bvRbb/uPlEvLbJOq69k3nKWDsgZ+f8n7/V/NwoyT71C8my6GVGvudMmuNYiBkoywQSbDDWdP3 uiCxbkdZdY38lTwKiH2nPsbieKU1CWi8I3XrpvuivgWU9DBIhABYdUztL8gb2CIXn29YEy0U8 DCvrVCHQGOLWqvR/y1CjagFqKd5juPD9kwrunDgM2vrjQa8NZHdCgEj7OrmzbZOqcfzRjLFKR aMahGlx4hnKo7rX7CkeSJyMxh2m4cYRlon7bC2dCQtCmte5wcdTIlj8qqq+tcKHCfwN0= Subject: Re: [Caml-list] why is building ocaml hard? --=-3NwyqUNIw2jEvaSgoeD5 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Am Montag, den 11.07.2016, 16:22 +0900 schrieb Fr=E9d=E9ric Bour: > - the compiler driver can produce multiple files on a single > invocation. File level dependencies turn into an hypergraph rather > than a graph (making a Makefile driven system hardly stable) Just a comment on this point. This is actually not a big problem when you record which rules have already been run, because then you can consider file1 file2 file3: file4 file5 file6 cmd just as file1: file4 file5 file6 cmd file2: file4 file5 file6 cmd file3: file4 file5 file6 cmd This is what omake does (and the rules are identified by their MD5 digests, which is very reliable). The limitation is that you cannot handle overlapping targets well, something like file1 file2: file4 cmd1 file1 file3: file4 cmd2 but this is something hardly any build system can do (i.e. alternate rules). Gerd > - an ML file alone is hard to understand out of context, because build > specification are kept separate > - many names and partially overlapping concepts; top-modules, > libraries, ocamlfind packages, opam packages. >=20 > On 07/11/2016 03:15 PM, Martin DeMello wrote: >=20 > > On Sun, Jul 10, 2016 at 4:03 AM, Gerd Stolpmann > > wrote: > > 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 > >=20 > > Would an acceptable third option be to simply record the dag > > explicitly in your build file? Working with google's build system > > [opensourced as bazel: http://www.bazel.io/] has given me a great > > appreciation for simply writing out build dependencies manually; > > sure, it is relatively tedious to have to write out the graph > > yourself rather than have ocamldep figure it out, but the time and > > effort to do so is a small fraction of the overall development time > > of your project, and the reward is a 100% reliable "detection" of > > the build topology. > >=20 > >=20 > > martin=20 >=20 --=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 ------------------------------------------------------------ --=-3NwyqUNIw2jEvaSgoeD5 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 iQEcBAABAgAGBQJXg3apAAoJEAaM4b9ZLB5TgygH/1zEmk4dS3LlukF4zMwTXxgh YHAULf+4Wr6BnGo7S2KUmTp9i4OxLe3bGGLxGXTAmdv/qZ5NR2k7z+MeehYWJPI4 cWCsMGkp5IjHzMLWezg0nCe1sU7xF6flgmT/qtdzJ5oLlkfGY+WGbJNPcT2tWvUl QlQHCHZO4Mg3zCrT8Knjw7ZNia02IZbLE4nZ6eLSz125qEAH58nxHYIgqMK5H3OG KU15aJToypvcdbghECetGhxlL6Eq7BGgvT76Ej+j5xeh9STc7MvdxHdxBn5hPJsJ 5fXKlhEeeJw8HkymHHx+W6olJ97t7jA1CrVOwO6PfWVNVFw42AlQIZCvtk3gVr4= =WCGc -----END PGP SIGNATURE----- --=-3NwyqUNIw2jEvaSgoeD5--