From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p3HKn9qv024257
	for <caml-list@sympa-roc.inria.fr>; Sun, 17 Apr 2011 22:49:09 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYEAHNRq02K54gDgWdsb2JhbACET6ENFAEBFiYlskiPRoEpg056BI4Dg3U
X-IronPort-AV: E=Sophos;i="4.64,229,1301868000"; 
   d="scan'208";a="106104778"
Received: from rouge.crans.org ([138.231.136.3])
  by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 17 Apr 2011 22:49:03 +0200
Received: from localhost (localhost.crans.org [127.0.0.1])
	by rouge.crans.org (Postfix) with ESMTP id 40EDB8285;
	Sun, 17 Apr 2011 22:49:03 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at crans.org
Received: from rouge.crans.org ([10.231.136.3])
	by localhost (rouge.crans.org [10.231.136.3]) (amavisd-new, port 10024)
	with LMTP id Y4beGaVyI8rg; Sun, 17 Apr 2011 22:49:03 +0200 (CEST)
Received: from [192.168.39.1] (fbx.up7.fr [88.185.141.188])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	by rouge.crans.org (Postfix) with ESMTPSA id 1135080E4;
	Sun, 17 Apr 2011 22:49:00 +0200 (CEST)
Message-ID: <4DAB523C.1030103@glondu.net>
Date: Sun, 17 Apr 2011 22:49:00 +0200
From: =?UTF-8?B?U3TDqXBoYW5lIEdsb25kdQ==?= <steph@glondu.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110402 Icedove/3.1.9
MIME-Version: 1.0
To: Alexy Khrabrov <deliverable@gmail.com>
CC: caml-list <caml-list@inria.fr>
References: <4D64C4F9-251E-4E76-8269-361C444E8F8F@gmail.com>
In-Reply-To: <4D64C4F9-251E-4E76-8269-361C444E8F8F@gmail.com>
X-Enigmail-Version: 1.1.2
OpenPGP: id=49881AD3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p3HKn9qv024257
Subject: Re: [Caml-list] swapping variant modules via subdirectories fails
 at link time

Le 15/04/2011 01:32, Alexy Khrabrov a écrit :
> With that a.cmi at the root level, I can remake prog.opt fine.  If I copy or symlink a.cmi to var/, or symlink a.mli there, and try to make prog.var.opt, I get an error at prog.ml that files var/a.cmx and x.cmx make inconsistent assumptions about the interface A.

Aren't you facing inconsistent assumptions over *implementations* instead?

You have to compile your two implementations of A in separate
directories, and compile whatever depends on A in your root directory
with only a.cmi (for example), so that no a.cmx is seen. Then you can
link using either .cmx file.

The reason is that the compiler uses information from .cmx files if they
are available to do some optimizations such as inling. These
optimizations are turned off (but compilations still succeeds) if the
.cmx are missing.

Maybe I can make it clearer with an example tree:

.
|-- a.cmi
|-- a.mli
|-- dir1
|   |-- a.cmi -> ../a.cmi
|   |-- a.cmx
|   |-- a.ml
|   |-- a.mli -> ../a.mli
|   `-- a.o
`-- dir2
    |-- a.cmi -> ../a.cmi
    |-- a.cmx
    |-- a.ml
    |-- a.mli -> ../a.mli
    `-- a.o

Of course, dir1 and dir2 must *not* be in the include patch when
compiling stuff depending on module A.

The ocamlobjinfo (in 3.12) or dumpapprox (in < 3.12) can be useful here:
no A must appear in "implementation assumptions" in whatever
reverse-dependencies of A if you intend to provides several
implementations of A.


Hope this helps,

-- 
Stéphane