From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p3HKQj2S023174 for ; Sun, 17 Apr 2011 22:26:45 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQBADlMq03RVdivimdsb2JhbAClVAgUAQEBCgkNBxIGIYhvnz+KbYIjg1MwiF0BAQMGhWsEjgODdX6CU4IaOg X-IronPort-AV: E=Sophos;i="4.64,228,1301868000"; d="scan'208";a="93326394" Received: from mail-qy0-f175.google.com ([209.85.216.175]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 17 Apr 2011 22:26:39 +0200 Received: by qyk35 with SMTP id 35so734078qyk.6 for ; Sun, 17 Apr 2011 13:26:38 -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=vSRXf05W0aRLrafXuHaX3/NS4oco4TvYFx8kwW0x5Eg=; b=VWzDcK9r0O08g6kelpWLaiRHgP6NeqSBdw7dBhobyezBPKg7sMb1wKcFkE5mkWPPLU vypsrnIAzEnAExfqG6/EuNCUa4akaFKRMqOoMdR05d8NPFGV2ijNMQS8Puy7WLWOx8HM 6D1rLXmq5nugfrCm+OUF45mbUxbYOXHzwq6Go= 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=sl15SYB0hBvoeEEetqANMiHAoZ42LhzX3NzHMr1ppYDFYWp8E0Mnc6WjKhdCVGV7UV ZIQuMXq948O7JJOzUCYaV0m295YQexomJ0JMP/aBTImss3yCGz5raMH2iMoKSQYMwNvL 3CoNYzlJ7IOJkZjUqNuBP6Yy3QGSKyAL/mdMg= Received: by 10.224.183.206 with SMTP id ch14mr2058946qab.343.1303071998305; Sun, 17 Apr 2011 13:26:38 -0700 (PDT) Received: from [10.81.10.252] (pat32.dartmouth-secure.border1-cfw.dartmouth.edu [129.170.241.32]) by mx.google.com with ESMTPS id s16sm3557201qco.13.2011.04.17.13.26.36 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Apr 2011 13:26:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Alexy Khrabrov In-Reply-To: <87pqongbah.fsf@frosties.localnet> Date: Sun, 17 Apr 2011 16:26:34 -0400 Cc: caml-list Message-Id: References: <4D64C4F9-251E-4E76-8269-361C444E8F8F@gmail.com> <87pqongbah.fsf@frosties.localnet> To: Goswin von Brederlow X-Mailer: Apple Mail (2.1082) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p3HKQj2S023174 Subject: Re: [Caml-list] swapping variant modules via subdirectories fails at link time On Apr 15, 2011, at 4:37 AM, Goswin von Brederlow wrote: > Alexy Khrabrov writes: > >> I have a module a.ml, containing some functions I want to alter in a version of my program. I'd like to do it on the command line at link time, to obtain either the original, or an altered version. >> >> Here's the original make line, simplified: >> >> %.cmx: %.ml >> ocamlfind ocamlopt $(DEBUG) $(OPTFLAGS) -package $(PACKAGES) -c $^ -o $@ >> >> prog.opt: lib.cmxa a.cmx x.cmx prog.ml >> ocamlfind ocamlopt $(DEBUG) $(OPTFLAGS) -package $(PACKAGES) -linkpkg $^ -o $@ >> >> I tried to create the variant by placing an altered version of a.ml in a subdirectory, var/, and linking that: >> >> prog.var.opt: lib.cmxa var/a.cmx x.cmx prog.ml >> ocamlfind ocamlopt $(DEBUG) $(OPTFLAGS) -package $(PACKAGES) -linkpkg $^ -o $@ >> >> Further, I've created a.mli at the root level, and compiled it with >> >> ocamlfind ocamlc a.mli >> >> -- it needs lib.cmo to work, a byte-code version of lib.cmxa, which I make first. >> >> 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. >> >> The var/a.cmx is made by the same above pattern rule as ./a.cmx. Even when ./a.cmi and var/a.cmi are the same, the same inconsistent error shows up! Renaming ./a.ml out of the way and symlinking var/a.ml to ./ remakes prog.opt fine, which I can then rename prog.var.opt manually and hope to do it every time I need that, yet it's tiresome. What prevents the original scheme from working? >> >> -- Alexy > > You need to compile a.ml inside var/ instead of compiling var/a.ml. > > MfG > Goswin I tried to do that, and found that my type definitions have all to be present -- so I had to symlink or copy *.cmi to var/. Even then, I couldn't get a top-level cmx to accept the equivalence of a.cmx to var/a.cmx. This is really disappointing, and makes me think about OCaml compilation model. In order for the type inference to see that your type definitions are equivalent, it uses all the .cmi files in scope without telling you so explicitly. Moving even one .cmx into a subdirectory is nearly impossible unless you check every type and see where it was defined, and make sure the subdirectory has access to these .cmi files; even then I get an error that two files make inconsistent assumptions about the implementation which is one of them. Good old C has separate compilation working, which doesn't work for OCaml so easily. A command line which links fine will fail if you move a file into a subdirectory and the debugging process is utterly non-trivial. Doesn't anybody work with versions of the same module compiled to be swappable, against the same .mli?! -- Aexy