xclerc / ocamljava

http://www.ocamljava.org
Other
172 stars 14 forks source link

Inconsistent assumptions in compiler-libs interfaces #8

Open yallop opened 10 years ago

yallop commented 10 years ago

OCaml-Java 2.0-alpha1, freshly-installed from OPAM, has the following problem:

$ cat t.ml 
let g _ = Lambda.is_guarded
let h _ = Bytegen.reset
$ ocamljava -c -I +compiler-libs t.ml
File "t.ml", line 1:
Error: The files /home/jeremy/.opam/ocamljava-2.0-alpha1/lib/ocaml/compiler-libs/lambda.cmi
       and /home/jeremy/.opam/ocamljava-2.0-alpha1/lib/ocaml/compiler-libs/bytegen.cmi
       make inconsistent assumptions over interface Lambda

The ocamlobjinfo tool shows that the crcs are indeed different:

$ ocamlobjinfo bytegen.cmi lambda.cmi | grep Lambda
    f4443f50b0df5f177b11fcb7305bac35    Lambda
Unit name: Lambda
    e86623cfe85b127520d0debaecc42ab2    Lambda
xclerc commented 10 years ago

There is clearly a bug in the build/install scripts. However, what you observe is the mere symptom of a deeper problem: compiler-libs contains one version of the Lambda module while two versions actually exist during the build: one for the ocamlc and ocamlopt compilers, and one for the ocamljava compiler (in the latter case, the lambda structure is extended with additional cases, and some typing information from previous phases is also kept).

Your reproduction case shows that the version actually installed in compiler-libs is the one for ocamljava. To me, the bug is that the Bytegen module should not be installed as it cannot be used.

Now, another possibility would be to patch the code of the ocamlc and ocamlopt compilers to use the extended lambda structure, and just ignore the additional elements. This is slightly heavier and would imply maintenance costs, but if you have an interesting use case...