Gabriel, there is in deed an issue, because when you compile a .ml file
and there is no .cmi file in the same directory, a new .cmi is created
(even if the .cmi is in the search path - compilation units must be in
the same directory).

This situation might be considered as an error by the compiler.

Gerd

Am Montag, den 08.08.2016, 19:03 +0200 schrieb Gabriel Scherer:
> It is correct that ocamldep assumes that the .ml and .mli of a given
> module are at the same place, but this is not the case for the rest of
> the compilation chain, which is either concerned with single source
> files (a .ml file or a .mli file) or with "compilation units" (a .cmo
> and .cmi files passed together, independently of where their source
> files were). In particular, all type-checking tools do look in -I
> directories to find .cmi files for the dependencies of the module
> being compiled (and at this stage they do not care for .mli files).
> 
> On Mon, Aug 8, 2016 at 6:09 PM,  <moosotc@gmail.com> wrote:
> >
> > It appears that .mli ought to always reside in the same directory
> > corresponding .ml lives in. Here's a simple shell script to illustrate
> > (probably a good idea to run inside freshly created temporary
> > directory):
> >
> > #!/bin/sh
> > set -x
> > rm -fr a* d
> >
> > touch a.ml
> > ocamldep a.ml
> > ocamlc -c a.ml || echo no cookie 1
> > ls
> > rm -f a* *.cm*
> >
> > touch a.ml a.mli
> > ocamldep a.ml
> > ocamlc -c a.ml || echo no cookie 2 && ls
> > ocamlc -c a.mli && ls
> > ocamldep a.ml
> > ocamlc -c a.ml || echo no cookie 3 && ls
> > rm -f a*
> >
> > mkdir -p d
> > touch a.ml d/a.mli
> > ocamldep -I d a.ml
> > ocamlc -I d -c a.ml
> > ls
> >
> > Transcript:
> > + rm -fr 'a*' d
> > + touch a.ml
> > + ocamldep a.ml
> > a.cmo :
> > a.cmx :
> > + ocamlc -c a.ml
> > + ls
> > a.cmi
> > a.cmo
> > a.ml
> > repro.sh
> > + rm -f a.cmi a.cmo a.ml a.cmi a.cmo
> > + touch a.ml a.mli
> > + ocamldep a.ml
> > a.cmo : a.cmi
> > a.cmx : a.cmi
> > + ocamlc -c a.ml
> > File "a.ml", line 1:
> > Error: Could not find the .cmi file for interface a.mli.
> > + echo no cookie 2
> > no cookie 2
> > + ls
> > a.ml
> > a.mli
> > repro.sh
> > + ocamlc -c a.mli
> > + ls
> > a.cmi
> > a.ml
> > a.mli
> > repro.sh
> > + ocamldep a.ml
> > a.cmo : a.cmi
> > a.cmx : a.cmi
> > + ocamlc -c a.ml
> > + ls
> > a.cmi
> > a.cmo
> > a.ml
> > a.mli
> > repro.sh
> > + rm -f a.cmi a.cmo a.ml a.mli
> > + mkdir -p d
> > + touch a.ml d/a.mli
> > + ocamldep -I d a.ml
> > a.cmo :
> > a.cmx :
> > + ocamlc -I d -c a.ml
> > + ls
> > a.cmi
> > a.cmo
> > a.ml
> > d
> > repro.sh
> >
> > In essence: if one needs a variant build with some module providing the
> > same interface but different implementations (in different directories)
> > ocaml(c|opt|dep) will force this person to have the same (stable and
> > unchanging) .mli in those implementation specific directories.
> >
> > Section 2.5 of the manual does not specify the relative file-system
> > locations of interface/implementation files, but typing/typemod.ml, if I
> > am reading it correctly, forces specific layout.
> >
> > So it would have been nice to either lift this restriction (i.e. have
> > ocaml[c|opt|dep] look inside -I supplied directories or spell out the
> > requirements in the documentation.
> >
> > --
> > mailto:moosotc@gmail.com
> >
> > --
> > Caml-list mailing list.  Subscription management and archives:
> > https://sympa.inria.fr/sympa/arc/caml-list
> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> > Bug reports: http://caml.inria.fr/bin/caml-bugs
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------