RE: [Caml-list] Interface(.mli) location

[David Allsopp <dra-news@metastack.com>]

moosotc@gmail.com wrote:
> David Allsopp <dra-news@metastack.com> writes:
> 
> > moosotc@gmail.com wrote:
> >> David Allsopp <dra-news@metastack.com> writes:
> >>
> >> > moosotc@gmail.com wrote:
> >> >> David Allsopp <dra-news@metastack.com> writes:
> >> >> > moosotc@gmail.com wrote:
> >> >> >> Gabriel Scherer <gabriel.scherer@gmail.com> writes:
> >> >> >>
> >> >> >> > 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).
> >> >> >>
> >> >> >> But the script seems to (somewhat) contradict this, i.e. after
> >> >> >> `ocamlc -I d -c a.ml' ocamlc ignores the presence of .mli
> >> >> >> inside subdirectory d/, producing both .cmi/.cmo when when
> compiling a.ml.
> >> >> >
> >> >> > The -I option specifies extra directories for compiled files
> >> >> > only, so it's correct that the compiler ignores d/a.mli.
> >> >>
> >> >> After sending the first post I've realized that: ocamlc -c d/a.mli
> >> >> was forgotten, but even after adding that to the script things do
> >> >> not change, i.e. following compilation of a.ml with -I d where d
> >> >> contains a.cmi still produces both a.cmo and a.cmi in the top-level
> directory.
> >> >
> >> > Indeed - but that's the correct documented behaviour, even if not
> >> > necessarily the ideal. There are various things you can do:
> >> >
> >> > a) Delete ./a.cmi as part of your build procedure. This isn't
> >> > ideal, though, because you lose the type-checking against d/a.cmi
> >> > b) Have an empty ./a.mli but never compile it - the compiler will
> >> > then unify ./a.cmo against d/a.cmi. This isn't ideal because having
> >> > a source file which you don't expect to compile will confuse
> >> > dependency generators and automatic build rules.
> >> > c) Implement a new option in the compiler driver which suppresses
> >> > the automatic generation of .cmi files (e.g. ocamlc -c -I d -no-cmi
> >> > a.ml)
> >>
> >> d) Make the compiler skip generation of .cmi if it sees one in the -I
> >>    directories?
> >
> > Of course, there is a dirty option e) if you have a.mli and a.cmi in
> > directory d as before:
> >
> > ocamlc -intf-suffix .ml -I d -c a.ml
> >
> > will use the .cmi in d and not generate one in the current directory...
> >
> 
> It's hairier than that when you think about -o (i.e. outputs go to the
> specific build directory instead of the source tree)

I'm probably being slow, but rather than just stating that it's hairier than I think, could you give an example of how -o makes any difference to that?

The somewhat dirty use of -intf-suffix means that the compiler will always find a ".mli" file, and so will always *look* for a .cmi file (and so find it in the -I directories in your case) and not write one *anywhere*, regardless of -o


David