Re: [Caml-list] swapping variant modules via subdirectories fails at link time

[Alexy Khrabrov <deliverable@gmail.com>]

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