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 931AA7F106 for ; Mon, 18 Jul 2016 16:47:51 +0200 (CEST) IronPort-PHdr: 9a23:rmVclhO0VK5OvT7UYrEl6mtUPXoX/o7sNwtQ0KIMzox0KPv9rarrMEGX3/hxlliBBdydsKMczbaH+P+wEUU7or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkItf6KuS9aU05X8iLD60qaQSj0AvCC6b7J2IUf+hiTqne5Sv7FfLL0swADCuHpCdrce72ppIVWOg0S0vZ/or9ZLuh5dsPM59sNGTb6yP+FhFeQZX3waNDUT5cbo/TLDRBOK731UBmMdkhNQBgHDxBPzWJrqrjH3u/Y70y6fa57YV7cxDB2m5qZtADHyiTwMN3Zt+WXei8o2grhauxmhjxhy04/aYceeM/8oLfCVRs8TWWcUBpUZbCdGGI7pKtJXV+c= Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=alain.frisch@lexifi.com; spf=None smtp.mailfrom=alain.frisch@lexifi.com; spf=None smtp.helo=postmaster@mx20.yaziba.net Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain.frisch@lexifi.com) identity=pra; client-ip=85.233.204.164; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="alain.frisch@lexifi.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain.frisch@lexifi.com) identity=mailfrom; client-ip=85.233.204.164; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="alain.frisch@lexifi.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mx20.yaziba.net) identity=helo; client-ip=85.233.204.164; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="postmaster@mx20.yaziba.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CTAgCB64xXh6TM6VVbhBUqUrp1GoYAAoEyPBABAQEBAQEBAREBAQEKCwkJIS+CMgQBEgGCEwEFIxVBEAsOCgICERUCAlcGDQgBAReIGbAijXIBAQEBAQUCASSBAYUpgXiCVYR/gkKCWgWZJIFejQGJUIVnkBwCNYI7gVlshz4BAQE X-IPAS-Result: A0CTAgCB64xXh6TM6VVbhBUqUrp1GoYAAoEyPBABAQEBAQEBAREBAQEKCwkJIS+CMgQBEgGCEwEFIxVBEAsOCgICERUCAlcGDQgBAReIGbAijXIBAQEBAQUCASSBAYUpgXiCVYR/gkKCWgWZJIFejQGJUIVnkBwCNYI7gVlshz4BAQE X-IronPort-AV: E=Sophos;i="5.28,384,1464645600"; d="scan'208";a="227036585" Received: from mx20.yaziba.net ([85.233.204.164]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jul 2016 16:47:51 +0200 Received: from mta10.int.yaziba.net (mta10.int.yaziba.net [10.4.20.30]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx20.yaziba.net (mx10.yaziba.net) with ESMTPS id 0553A1A78A6; Mon, 18 Jul 2016 16:47:51 +0200 (CEST) Received: from mta10.int.yaziba.net (localhost [127.0.0.1]) by mta10.int.yaziba.net (Postfix) with ESMTPS id F30E2CA73A; Mon, 18 Jul 2016 16:47:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mta10.int.yaziba.net (Postfix) with ESMTP id E1E17CA755; Mon, 18 Jul 2016 16:47:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at mta10.int.yaziba.net Received: from mta10.int.yaziba.net ([127.0.0.1]) by localhost (mta10.int.yaziba.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zglhII0D-rWw; Mon, 18 Jul 2016 16:47:50 +0200 (CEST) Received: from [10.0.210.48] (unknown [185.23.92.144]) by mta10.int.yaziba.net (Postfix) with ESMTPSA id BAE98CA73A; Mon, 18 Jul 2016 16:47:50 +0200 (CEST) To: Nick Chapman References: Cc: OCaml Mailing List From: Alain Frisch Message-ID: Date: Mon, 18 Jul 2016 16:47:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-DRWEB-SCAN: ok X-VRSPAM-SCORE: -100 X-VRSPAM-STATE: legit X-VRSPAM-CAUSE: gggruggvucftvghtrhhoucdtuddrfeeltddrgeelgdekvdcutefuodetggdotefrucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpjgetkgfkueetnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefuvfhfhffkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpeetlhgrihhnucfhrhhishgthhcuoegrlhgrihhnrdhfrhhishgthheslhgvgihifhhirdgtohhmqeenucfkphepudekhedrvdefrdelvddrudeggeenucfrrghrrghmpehmohguvgepshhmthhpohhuth X-VRSPAM-EXTCAUSE: mhhouggvpehsmhhtphhouhht Subject: Re: [Caml-list] ocamldep, transitive dependencies, build systems, flambda Thanks to everyone who commented on my message! On 05/07/2016 11:17, Nick Chapman wrote: > There was a further issue we needed to solve to get our scheme working. > Suppose library A lists library B as a dependency and allows this > dependence to be exposed in its interface. Clients of library A will > require access to the .cmi's of library B to be compiled but it seems > unreasonable to require them to explicitly list library B as a > dependency. We solve this by automatically running ocamlinfo on the > public .cmi's of a library to discover additional library deps required > by clients of the library. I think this is another instance of the same problem, namely that there as "implicit" dependencies that cannot be seen by ocamldep. It's just reduced a bit thanks to the less fine-grained dependency analysis across libraries (which we try to avoid in our case). If we wanted to use the same trick on a per file-basis, one would need to inject dynamic dependencies (obtained after compilation), but I don't see how to do that with our omake-based build system. Have you had to change some build rules to account for flambda (I guess you must now look for implementation deps in .cmx in addition to interface deps in .cmi)? Here is the solution we you have adopted for now for our experiments with flambda. We apply the same "dependency restriction" for .cmx files as we do for .cmi files, namely: whenever the compiler tries to open A.cmx when compiling B.ml, it does as if A had been compiled with -opaque unless A is an explicit dependency of B.ml (i.e. ocamldep would see "A" when analyzing "B.ml"). In effect, this will prevent some cross-module optimizations, but we don't see how to do better without significantly changing our build strategy. This solution is similar to Hongbo's comment about cross-module inlining in Bucklescript. Alain