From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p3JH9mDS010825 for ; Tue, 19 Apr 2011 19:09:48 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApACAObArU3RVdivkGdsb2JhbAClJAgUAQEBAQkJDQcUBCGIb6A4inSCJYUaMYhdAQEDBoVrBI4Hg3yBAIR6Og X-IronPort-AV: E=Sophos;i="4.64,240,1301868000"; d="scan'208";a="81373213" Received: from mail-qy0-f175.google.com ([209.85.216.175]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 19 Apr 2011 19:09:43 +0200 Received: by qyk35 with SMTP id 35so2031111qyk.6 for ; Tue, 19 Apr 2011 10:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=dIPe1JH4+7E5Fqz6pREq7RBmmbyT1rqCwBtv4oUEPuU=; b=a5Lh6m8mzhQcm4TC+hZ710kd0aCrd2wxHuBkQ4zDZ8SG02t4mIg5ClbxSIusa9XB1B eLQ3vGNbDK2ALirasJVdjQA/lyIGCgl2gUOiJ7gz7u44OUExYtoiiIdVVa6K3Y3r3Wub +3zSJNeZXmjr9CROpdBscp8EfH0zP0GDfhiYM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=gIWdR5b5mjA423xzc/CQQRgjxXYKxEd5O0qGhSR3bY0tnnydI1+fr2SAXyvP9OnP+v PkLfMalhMRKHDG2qxcxoQfvsXNCbBfHbI2htZHsBSD3ScKnuj1rQi1yRgVBZcC+j9WyF Q5pcZGOrZy1cPmT4T7K88IIvmg2nh9mmn2HXU= Received: by 10.229.88.197 with SMTP id b5mr4558159qcm.226.1303232981867; Tue, 19 Apr 2011 10:09:41 -0700 (PDT) Received: from [192.168.10.81] (host2.tuckerb-gw.cust.sover.net [207.136.251.178]) by mx.google.com with ESMTPS id f5sm66811qck.8.2011.04.19.10.09.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2011 10:09:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Alexy Khrabrov In-Reply-To: <4DAB523C.1030103@glondu.net> Date: Tue, 19 Apr 2011 13:09:37 -0400 Cc: caml-list Message-Id: References: <4D64C4F9-251E-4E76-8269-361C444E8F8F@gmail.com> <4DAB523C.1030103@glondu.net> To: =?iso-8859-1?Q?St=E9phane_Glondu?= X-Mailer: Apple Mail (2.1082) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p3JH9mDS010825 Subject: Re: [Caml-list] swapping variant modules via subdirectories fails at link time On Apr 17, 2011, at 4:49 PM, Stéphane Glondu wrote: > 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. Stéphane -- this is great, thanks! Although in my case, I need highly optimal executable, so I'm willing to symlink files from their subdirectories onto the top level and link everything there. Yet I'll use the technique when I need to quickly swap implementations without recompiling, and most importantly, without renaming/resymlinking, when I need to compare versions. This is great as each separate .cmx can be used under its own path in a Makefile, leading to several distinctly named executables. Embedding a string in each .cmx can also allow status reporting, etc. -- Alexy