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 BB05F7FE44 for ; Tue, 5 Jul 2016 15:18:04 +0200 (CEST) IronPort-PHdr: 9a23:UbZckhAR3Ktz/5jBk2+RUyQJP3N1i/DPJgcQr6AfoPdwSP7zpsbcNUDSrc9gkEXOFd2CrakV06yM7+u9CCQp2tWoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09fr2zQd+KyZ7rnL3js7ToICxwzAKnZr1zKBjk5S7wjeIxxbVYF6Aq1xHSqWFJcekFjUlhJFaUggqurpzopM0r221qtvkg789NV7nhN+R9FOQATWduD2dgxMrtuhPEBTmP730TGjEWgBpBBQefvUzSVJP2tS7wu/Byni+XIZulY6ozXGGN5q1xSRLswBwMNzMj/Xuf3sN5hrharRbnvBd/zpTZeqmaMfN/euXWetZMFjkJZdpYSyEUWtD0VIAIFedUeL8A94Q= Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=gabriel.scherer@gmail.com; spf=Pass smtp.mailfrom=gabriel.scherer@gmail.com; spf=None smtp.helo=postmaster@mail-io0-f170.google.com 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.223.170; 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.223.170 as permitted sender) identity=mailfrom; client-ip=209.85.223.170; 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-io0-f170.google.com) identity=helo; client-ip=209.85.223.170; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-io0-f170.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CgAAB1sntXhqrfVdFchRAGrg2NKYYYAoEqBzwQAQEBAQEBAQERAQEBCAsLCSEvgjKCGgEBBAESER0BGx0BAwELBgULAwcCKwICIgERAQUBFAgGEyKHcwEDDwidIoExPjGLO4FqgloFhgIKGScNUoM8AQEBAQEBAQECAQEBAQEBARgCBhCGF4RNh0GCWgWZE4FYhSGHToFqjUCOSxIegQ81gicRC4FoIDKIeQEBAQ X-IPAS-Result: A0CgAAB1sntXhqrfVdFchRAGrg2NKYYYAoEqBzwQAQEBAQEBAQERAQEBCAsLCSEvgjKCGgEBBAESER0BGx0BAwELBgULAwcCKwICIgERAQUBFAgGEyKHcwEDDwidIoExPjGLO4FqgloFhgIKGScNUoM8AQEBAQEBAQECAQEBAQEBARgCBhCGF4RNh0GCWgWZE4FYhSGHToFqjUCOSxIegQ81gicRC4FoIDKIeQEBAQ X-IronPort-AV: E=Sophos;i="5.26,579,1459807200"; d="scan'208,217";a="183930064" Received: from mail-io0-f170.google.com ([209.85.223.170]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 05 Jul 2016 15:18:03 +0200 Received: by mail-io0-f170.google.com with SMTP id f30so173180483ioj.2 for ; Tue, 05 Jul 2016 06:18:03 -0700 (PDT) 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; bh=e1oH8uli4IOyEi5df9IWcKyb84PKVmdLU6WI+9vlmOM=; b=TKfBWd4KAsE+Mky5eSNJuqFvoszT1N+j7j7+1HcnrlImCTpwhH/oaqsvwfkW6l+6Z5 oiLGUmEmtHkhMg+N3RndsGgISg47PV5SuRec3JZeaw+bVjJH2DvfXvfzMkUlns5KuOqg ryOI7y3KK40WJ14jq3z6OMAFXUMkOcysrk/LXzQ2ED9WsqdaAvSc+cZQtLaXoZ+Msqie nIcBWpZQ+KNj4zwyxtqgHHO7/NEEcUnWMeZEEA9mkXsbtljPAOTPyOVULrB4l+vvptBF 60RHpZr/PvsxDQ6pCA4Jvfk4dXTpKUevKdVdlu2f+BPmMwyOifRzMO+jrZYQ3BJqf6A1 jipA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e1oH8uli4IOyEi5df9IWcKyb84PKVmdLU6WI+9vlmOM=; b=FdgX+VFoWzs2ubjAMJ27OvQGOJ8sQxY6j0g4FKk2bqYoRFI0pEdz4v+jF3AWNBo24H DdUbxNjaEF6mFKJtCcbpiLY8UMWyXA8W3jdqXnoQaxUjVO8Xe4UisZGgMDk+AiIPVNfb vpOFGAMPioPo8/FM03eOu04EjoZnMcBtGs6j67lStnwDSdHQtocHQ6O9/rW41OradQzq 3SO3uQdyel2498Y6vWz8X+AKw5pX6yt2zjg7OwgXAit3OMgfCg1H+Rw9a2L2pZQyH8m9 89jGsKO/wBOx5iNZ9IUTKN7GOQRYietxDiX0vU9G+9Bmxb6Q5w1s9wX278aedV3ULJrF UNAA== X-Gm-Message-State: ALyK8tIqsmEBqivqAnTyZrTuvaeARKKhki9hUu3IUUFAJk/DoXPcZpi6GuBcp3nw2/LnKvw3pgKDfzX440ddtQ== X-Received: by 10.107.26.137 with SMTP id a131mr12839353ioa.30.1467724681844; Tue, 05 Jul 2016 06:18:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.68.130 with HTTP; Tue, 5 Jul 2016 06:17:22 -0700 (PDT) In-Reply-To: <577BB0DE022B05020039036A_0_53469@p057> References: <577BB0DE022B05020039036A_0_53469@p057> From: Gabriel Scherer Date: Tue, 5 Jul 2016 09:17:22 -0400 Message-ID: To: Hongbo Zhang Cc: Alain Frisch , caml users Content-Type: multipart/alternative; boundary=001a113fd53e4a26d90536e3486d Subject: Re: [Caml-list] ocamldep, transitive dependencies, build systems, flambda --001a113fd53e4a26d90536e3486d Content-Type: text/plain; charset=UTF-8 I think that the question was more about how owner of large codebases approach the problem in practice today, but in terms of "what do people think about this" I would still stand by my comment on the mantis issue: ocamldep is an heuristic tool based on some assumptions about how OCaml > users typically organize their development. I'm not sure it is reasonable > to try to evolve it into an omniscient tool capable of dealing with your > sophisticated file manipulations. That's what "by hand" compilation scripts > (or special-case tools designed hand-in-hand with your quite specific build > system) are for: absolute flexibility. > > I'm not convinced in particular that doing deep modification to the > semantics of .cmi files and/or the compilation process to work around > limitations of ocamldep is such a good idea. > > I would rather welcome richer ways to inform the compiler of the mapping > from Ocaml world compilation unit names to filesystem object files than the > current rules allow; and/or potentially a type-checker design facilitating > discovery of dependencies and interaction with library providers and build > systems (implement what currently is ocamldep as a layer between parsing > and type-checking, that resolves such mapping, is able to access existing > .cmi files for semantically accurate naming information, and to make > asynchronous queries to a build system for the missing .cmi). That said, I also know that Alain has explored these options (eg. intercepting calls to other files in the compiler) further than many of thus, so he probably has good reasons for sticking to a practical compromise. On Tue, Jul 5, 2016 at 9:06 AM, Hongbo Zhang (BLOOMBERG/ 731 LEX) < hzhang295@bloomberg.net> wrote: > Hi Alain, > I found the same problem when we did aggressive cross-module inlining in > bucklescript. It makes it too hard to build a correct build system, so > currently the inlining will stop at B, it will not propagate to C, what do > other people think about this? > > From: alain.frisch@lexifi.com At: 07/04/16 12:49:32 > To: caml-list@inria.fr > Subject: Re:[Caml-list] ocamldep, transitive dependencies, build systems, > flambda > > > > Moreover, flambda makes the problem actually quite a bit worse. Indeed, > B.cmx can now contain symbolic references to A.cmx, and when compiling > C.cmx, the compiler will complain that it cannot find A.cmx (typically > when a function in B is inlined in C and calls a function in A). This > is warning 58. Simply disabling the warning does not work, since an old > version of A.cmx could remain in lib1/pub, leading to mismatched > implementation digests and to unreliable parallel build. > > > > --001a113fd53e4a26d90536e3486d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think that the question was more about how owner of larg= e codebases approach the problem in practice today, but in terms of "w= hat do people think about this" I would still stand by my comment on t= he mantis issue:

o= camldep is an heuristic tool based on some assumptions about how OCaml user= s typically organize their development. I'm not sure it is reasonable t= o try to evolve it into an omniscient tool capable of dealing with your sop= histicated file manipulations. That's what "by hand" compilat= ion scripts (or special-case tools designed hand-in-hand with your quite sp= ecific build system) are for: absolute flexibility.

I'm not conv= inced in particular that doing deep modification to the semantics of .cmi f= iles and/or the compilation process to work around limitations of ocamldep = is such a good idea.

I would rather welcome richer ways to inform th= e compiler of the mapping from Ocaml world compilation unit names to filesy= stem object files than the current rules allow; and/or potentially a type-c= hecker design facilitating discovery of dependencies and interaction with l= ibrary providers and build systems (implement what currently is ocamldep as= a layer between parsing and type-checking, that resolves such mapping, is = able to access existing .cmi files for semantically accurate naming informa= tion, and to make asynchronous queries to a build system for the missing .c= mi).

That said, I also know that Alain has= explored these options (eg. intercepting calls to other files in the compi= ler) further than many of thus, so he probably has good reasons for stickin= g to a practical compromise.
On Tue, Jul 5, 2016 at 9:06 AM, Hongbo Zhang (B= LOOMBERG/ 731 LEX) <hzhang295@bloomberg.net> wrote:
Hi Alain,
I found t= he same problem when we did aggressive cross-module inlining in bucklescrip= t. It makes it too hard to build a correct build system, so currently the i= nlining will stop at B, it will not propagate to C, what do other people th= ink about this?

From: alain.frisch@lexifi.com At: 07/= 04/16 12:49:32
To: caml-list@inria.fr
Subject: Re:[Caml-list] ocamldep, tra= nsitive dependencies, build systems, flambda


Moreover, flambda makes the problem actually quite a = bit worse. Indeed,
B.cmx can now contain symbolic references to A.cmx,= and when compiling
C.cmx, the compiler will complain that it cannot fi= nd A.cmx (typically
when a function in B is inlined in C and calls a fu= nction in A). This
is warning 58. Simply disabling the warning does n= ot work, since an old
version of A.cmx could remain in lib1/pub, leadin= g to mismatched
implementation digests and to unreliable parallel build= .



<= /div>
--001a113fd53e4a26d90536e3486d--