• Guillaume Melquiond's avatar
    Make sure that the opt and byte targets can be built concurrently. · 12b97bbb
    Guillaume Melquiond authored
    The main issue is that both ocamlc and ocamlopt write a .cmi file when
    there is no .mli file, so the .cmi file might end up being corrupted due
    to concurrent accesses.
    
    The ugly fix is to prevent ocamlopt from creating a .cmi file by lying to
    it: ".mli files are no interface files, .but cmi files are". So ocamlopt
    behaves as if there had been a .mli file in the first place and does not
    try to produce a compiled interface from the .ml file. Note that we use
    the .cmi file because it happens to have the same base name, but any other
    file would have worked, e.g. the .dep file, since ocamlopt does not even
    read the file to check that it is actually an interface file.
    
    Since ocamlopt now believes that the .ml file has an interface, it needs a
    compiled interface to check its signature against, so the .cmi file has to
    be created beforehand. So the .cmx file is made to depend on the .cmi file
    and the .cmi file on the .cmo file.
    
    This might seem to add a dependency from the opt build on the byte build,
    but since ocamldep already says that the tools depend on lib/why3/why3.cmo
    due to the pack, this does not make the situation any worse.
    
    Note that there is a single file for which the .cmi hack cannot be used:
    src/tools/why3extract.ml. Indeed, if we lie to ocamlopt, it will try to
    use lib/why3/why3extract.cmi as the compiled interface (?!) and thus fail
    to compile src/tools/why3extract.ml, obviously. So the hack is disabled
    for this file, which means that src/tools/why3extract.cmi could end up
    being corrupted, but we do not care.
    12b97bbb
Makefile.in 64.4 KB