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 35F777EE7D for ; Tue, 2 Jun 2015 10:35:05 +0200 (CEST) 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.187; 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.187; 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.187; 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: A0CDAQAVam1Vm7t+49RbgyU/XsA6CoV3AoE0PBABAQEBAQEBEQEBAQEBBgsLCSEuhCMBAQRVJBALDjhXBhMJiCgJtHshbw2icQEBAQEBAQEDAQEBAQEdi0OEYCYHgi0MQYEzBYZrjQMCg1aGYId5A488gl6BP20BgkYBAQE X-IPAS-Result: A0CDAQAVam1Vm7t+49RbgyU/XsA6CoV3AoE0PBABAQEBAQEBEQEBAQEBBgsLCSEuhCMBAQRVJBALDjhXBhMJiCgJtHshbw2icQEBAQEBAQEDAQEBAQEdi0OEYCYHgi0MQYEzBYZrjQMCg1aGYId5A488gl6BP20BgkYBAQE X-IronPort-AV: E=Sophos;i="5.13,538,1427752800"; d="asc'?scan'208";a="161401831" Received: from mout.kundenserver.de ([212.227.126.187]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jun 2015 10:35:04 +0200 Received: from office1.lan.sumadev.de ([178.4.18.152]) by mrelayeu.kundenserver.de (mreue002) with ESMTPSA (Nemesis) id 0MB724-1Ypm1f28w8-009yOO; Tue, 02 Jun 2015 10:34:51 +0200 Received: from [192.168.65.10] (unknown [192.168.65.10]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id B13AFDC05D; Tue, 2 Jun 2015 10:34:50 +0200 (CEST) Message-ID: <1433234082.11499.27.camel@e130.lan.sumadev.de> From: Gerd Stolpmann To: Josh Watzman Cc: "caml-list@inria.fr" Date: Tue, 02 Jun 2015 10:34:42 +0200 In-Reply-To: <7BA16901-A2D2-48DE-9DA4-065DF74D5B90@fb.com> References: <7BA16901-A2D2-48DE-9DA4-065DF74D5B90@fb.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-rFGd8xuhm9EgE9ql6HeU" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 X-Provags-ID: V03:K0:lfRbh23npbrePCJy4MYu7qv4JaS0VQfP6akSwJcZh6A/jXI0RzU 1z/ZTRD8AmyivGPEkSJztgx/j5LiNZ100NJ4XB3VHgm6yNmPsP/d5XoZM481VNQOiGiHHNX ijoJ1oLlRU0k03yi/YPZic9QL8+viBaXDVECt/A9qWienCbcRwjZAbBuIOJgQcXot31dGLz 5NGdFDTgYYsHmZ1WrKaKA== X-UI-Out-Filterresults: notjunk:1;V01:K0:cyl5bWTWDiw=:hy6MfCX9b+kF2OFgwewOnd TzAxdgInZAvqmGZ3M0XVt85LcFdmXtY59ZlaD8R4fre19y4AOIdmttx4yrY7EYsFxoM6q39db HfDWSjXkmaO+MIHmGiogmrrNppJW4cjqPymzr2kPH6rneM9xaqR5ScVXQRCFWYeXrCQBDuAQo v/x/kl0yDY/ZJzQkbNEFlm6vS6TZkyqYmye7Thbo8DpiPnHKSUGn67ov6+JzGXp0DJ2E7iNbR xaK5jO0tZl8CUM1DlWTK2tSo+K2qFyq+eZ7b1cncJVDLAY0HMujcTruHLCxpR+pShpfbbIC/b vw2w7kHFasUGuBBC3TeydbSlxHBhcrPWKRtJdsou4Kdv1Bc7JPmMRRxi/n5yBxYvQmxYszY+T dUeXKFtFGN7CwRmSXurcjD7PC3l2uhh3Pke+KBNLJhr/p8oy8Xq+xmTk0JJe2O+LZ38mce/qy 5d5ZFE6hW2KzO17ko6cOez1Ltq3k8CwWKyddOX/tX6Q2UUgCuRJ+drohxfDkKIPdKI57iwUce Nt0W5jwHrOTo/VBrxKWyswHLLdVcF/h/7+wTF8RdGKfbJH3MeXpxpgtUKWt8/YOleV869Q9na XZuiImjyEsZsfl8bmdMrTgwHw2SNfjtVP37eUlBgib9S7TLkx05+fsMTIqaFKkbpAtmjOOfmK bM45+uZo0ER7x7H5Sidc2u4Ok Subject: Re: [Caml-list] "Inconsistent assumptions" when moving files across subdirectories --=-rFGd8xuhm9EgE9ql6HeU Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable I would have thought ocamlbuild is immune to this problem because it puts the translated files into a separate directory tree. But maybe this problem was overlooked. In a more traditional "make" setup, you cannot distinguish between a cmi left over from a move and a "naked" cmi that intentionally is not accompanied by a ml/mli (i.e. a binary install). But this is exactly possible when files are copied to a build tree. Gerd Am Montag, den 01.06.2015, 21:52 +0000 schrieb Josh Watzman: > I've noticed that it's pretty easy to confuse ocamlc/ocamlopt when moving= a module across subdirectories. Here's an example, the most minimized repr= o I could get; it uses ocamlbuild, but a similar problem happens if you use= OCamlMakefile and I assume other build systems. https://gist.github.com/jw= atzman/9979951afb5b87304c18 -- running that will consistently terminate wit= h the dreaded >=20 > > Error: Files main.cmx and a/quux.cmx > > make inconsistent assumptions over interface Quux >=20 > (The script flips the quux module back and forth twice, but that's only t= o exhibit the problem on both 4.01 and 4.02; you can get the same problem w= ith only one move of quux.ml, but which way you need to move it depends on = which version of ocaml you're using.) >=20 > A clean build will of course resolve the problem, but that's quite annoyi= ng to have to go broadcast to a large team, particularly when the build may= take many minutes, and when this problem is specific to the OCaml parts of= our system (a humongous C++ codebase never requires a clean rebuild). Rena= ming a module across subdirectories doesn't seem like that uncommon of an o= peration. >=20 > The root problem seems to be that ocamlc/ocamlopt are picking up build ar= tifacts by directory only, and can't be explicitly told which artifacts to = pick up, and so they are picking up the "wrong" quux.cmi/cmx left over in a= build directory, which ocamlbuild should be cleaning up. Is that right? Is= there any way to tell ocamlc/ocamlopt not to do things by directory, but t= o be more explicit, for the usages of build systems? >=20 > Not working around this limitation of ocamlc/ocamlopt seems like a bug in= ocamlbuild, no? I'm a bit surprised by it though, given that I've found th= e same problem in other build systems -- have other folks not run into this= ? How do other teams deal with this, trying to avoid clean builds? >=20 > Thanks! > Josh Watzman >=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 ------------------------------------------------------------ --=-rFGd8xuhm9EgE9ql6HeU 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 iQEcBAABAgAGBQJVbWqjAAoJEAaM4b9ZLB5TBS4H/1M25e3dy82eZIv+ZU/6bwoq nIUyrQ6XIZkGddOOPGEjH7Q3DvLGj10vjAf+9Lh3gXpIE2D0pkH8M8fqK5uUmHpT XvWjGpi8co/usMGGv0oE4OjSX+SjEfoU0kds8Pmq1bzJcxn8Zu6rLLjrENuunjmM wHzkhVf1b/lIm1bFYRpWcBiJZ0L2EoEyx9CLdR013Ze0uqJfFVQEc0Kayvfdgitm QVks0TwYfD9lsuN7yhKa7PRxM2BF4JSCSFHs3nncsapwBVia1sm1xSh5GHOTFhZj 463GI8rMhs4bVFwSFM4XdfoUE4jE+QUvl6rO8GUhqgIThDDqB/NcihiOWLmXk6w= =h+XB -----END PGP SIGNATURE----- --=-rFGd8xuhm9EgE9ql6HeU--