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 D42497EE7D for ; Tue, 2 Jun 2015 00:16:16 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of boris@yakobowski.org) identity=pra; client-ip=87.98.172.75; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="boris@yakobowski.org"; x-sender="boris@yakobowski.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of boris@yakobowski.org designates 87.98.172.75 as permitted sender) identity=mailfrom; client-ip=87.98.172.75; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="boris@yakobowski.org"; x-sender="boris@yakobowski.org"; 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@4.mo2.mail-out.ovh.net) identity=helo; client-ip=87.98.172.75; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="boris@yakobowski.org"; x-sender="postmaster@4.mo2.mail-out.ovh.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DlAgA72WxVnEusYldcg2ReBoMYrF6ONoINhXcCgTIHPBABAQEBAQEBEQEBAQEBBg0JCSEuhCMBAQMBEhFLCwULCQILAxcdAgIiEgEFAQoSBhMSEId2AwoIBAEIlzWQaz4xiz+GVJgUA4UfAQEBAQEBBAEBAQEBARyKQYEChQIEB4JogUUFhUoKkXKGYIFplAUSI4EVgl6BP22CRwEBAQ X-IPAS-Result: A0DlAgA72WxVnEusYldcg2ReBoMYrF6ONoINhXcCgTIHPBABAQEBAQEBEQEBAQEBBg0JCSEuhCMBAQMBEhFLCwULCQILAxcdAgIiEgEFAQoSBhMSEId2AwoIBAEIlzWQaz4xiz+GVJgUA4UfAQEBAQEBBAEBAQEBARyKQYEChQIEB4JogUUFhUoKkXKGYIFplAUSI4EVgl6BP22CRwEBAQ X-IronPort-AV: E=Sophos;i="5.13,535,1427752800"; d="scan'208";a="132948059" Received: from 4.mo2.mail-out.ovh.net ([87.98.172.75]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 02 Jun 2015 00:16:15 +0200 Received: from mail605.ha.ovh.net (gw6.ovh.net [213.251.189.206]) by mo2.mail-out.ovh.net (Postfix) with SMTP id 3D17DFFBD0C for ; Tue, 2 Jun 2015 00:16:15 +0200 (CEST) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 2 Jun 2015 00:16:14 +0200 Received: from mail-la0-f46.google.com (boris@yakobowski.org@209.85.215.46) by ns0.ovh.net with SMTP; 2 Jun 2015 00:16:13 +0200 Received: by labko7 with SMTP id ko7so108491840lab.2 for ; Mon, 01 Jun 2015 15:16:12 -0700 (PDT) X-Received: by 10.112.219.70 with SMTP id pm6mr22617811lbc.41.1433196972523; Mon, 01 Jun 2015 15:16:12 -0700 (PDT) MIME-Version: 1.0 Reply-To: boris@yakobowski.org Received: by 10.112.26.242 with HTTP; Mon, 1 Jun 2015 15:15:51 -0700 (PDT) In-Reply-To: <7BA16901-A2D2-48DE-9DA4-065DF74D5B90@fb.com> References: <7BA16901-A2D2-48DE-9DA4-065DF74D5B90@fb.com> From: Boris Yakobowski Date: Tue, 2 Jun 2015 00:15:51 +0200 Message-ID: To: Josh Watzman Cc: "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=001a11c3ccd870c70805177c2c09 X-Ovh-Tracer-Id: 15685193077512845344 X-Ovh-Remote: 209.85.215.46 (mail-la0-f46.google.com) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: -51 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekuddrgeehucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenogfuuhhsphgvtghtffhomhgrihhnucdlgeelmd X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -51 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekuddrgeehucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenogfuuhhsphgvtghtffhomhgrihhnucdlgeelmd X-Validation-by: boris@yakobowski.org Subject: Re: [Caml-list] "Inconsistent assumptions" when moving files across subdirectories --001a11c3ccd870c70805177c2c09 Content-Type: text/plain; charset=UTF-8 Hi, I can confirm you're not alone, unfortunately. In Frama-C (which uses good ol' make), we have added a new target, dubbed 'smartclean', that removes all orphaned .cm*. More precisely, if there exists a .cm* without a corresponding .ml*, the .cm* is removed. This is quite hackish, and not entirely satisfactory. Still, it's always better than performing a full clean/rebuild. HTH, On Mon, Jun 1, 2015 at 11:52 PM, Josh Watzman wrote: > 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 repro > 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/jwatzman/9979951afb5b87304c18 -- running that > will consistently terminate with the dreaded > > > Error: Files main.cmx and a/quux.cmx > > make inconsistent assumptions over interface Quux > > (The script flips the quux module back and forth twice, but that's only to > exhibit the problem on both 4.01 and 4.02; you can get the same problem > with only one move of quux.ml, but which way you need to move it depends > on which version of ocaml you're using.) > > A clean build will of course resolve the problem, but that's quite > annoying 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). Renaming a module across subdirectories doesn't seem like that > uncommon of an operation. > > The root problem seems to be that ocamlc/ocamlopt are picking up build > artifacts 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 to be more explicit, for the usages of build systems? > > 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 the > 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? > > Thanks! > Josh Watzman > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs -- Boris --001a11c3ccd870c70805177c2c09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I can confirm you're not al= one, unfortunately. In Frama-C (which uses good ol' make), we have adde= d a new target, dubbed 'smartclean', that removes all orphaned .cm*= . More precisely, if there exists a .cm* without a corresponding .ml*, the = .cm* is removed.

This is quite hackish, and not entirely satisfactor= y. Still, it's always better than performing a full clean/rebuild.
<= br>
HTH,

= On Mon, Jun 1, 2015 at 11:52 PM, Josh Watzman <jwatzman@fb.com> wrote:
I've noticed that it's p= retty easy to confuse ocamlc/ocamlopt when moving a module across subdirect= ories. Here's an example, the most minimized repro I could get; it uses= ocamlbuild, but a similar problem happens if you use OCamlMakefile and I a= ssume other build systems. https://gist.github.com/jwatzman/997995= 1afb5b87304c18 -- running that will consistently terminate with the dre= aded

> Error: Files main.cmx and a/quux.cmx
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 make inconsistent assumptions over interfac= e Quux

(The script flips the quux module back and forth twice, but that's only= to exhibit the problem on both 4.01 and 4.02; you can get the same problem= with only one move of quux.ml= , but which way you need to move it depends on which version of ocaml y= ou're using.)

A clean build will of course resolve the problem, but that's quite anno= ying to have to go broadcast to a large team, particularly when the build m= ay 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). Re= naming a module across subdirectories doesn't seem like that uncommon o= f an operation.

The root problem seems to be that ocamlc/ocamlopt are picking up build arti= facts by directory only, and can't be explicitly told which artifacts t= o pick up, and so they are picking up the "wrong" quux.cmi/cmx le= ft over in a build directory, which ocamlbuild should be cleaning up. Is th= at right? Is there any way to tell ocamlc/ocamlopt not to do things by dire= ctory, but to be more explicit, for the usages of build systems?

Not working around this limitation of ocamlc/ocamlopt seems like a bug in o= camlbuild, no? I'm a bit surprised by it though, given that I've fo= und the same problem in other build systems -- have other folks not run int= o this? How do other teams deal with this, trying to avoid clean builds?

Thanks!
Josh Watzman


--
Caml-list mailing list.=C2=A0 Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
<= br>

--
Boris
--001a11c3ccd870c70805177c2c09--