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:
> >> >> moosotc@gmail.com writes:
> >> >>
> >> >> > moosotc@gmail.com writes:
> >> >> >
> >> >> >> David Allsopp <dra-news@metastack.com> writes:
> >> >> >>
> >> >> > [..snip..]
> >> >> >
> >> >> >>>>
> >> >> >>>> d) Make the compiler skip generation of .cmi if it sees one
> >> >> >>>> in the
> >> -I
> >> >> >>>>    directories?
> >> >> >>>
> >> >> >>> No - I think the use-case is too niche to justify breaking
> >> >> >>> backwards compatibility. That's potentially a very subtle way
> >> >> >>> to break someone else's existing build system. The existing
> >> >> >>> behaviour is precisely documented in the manual (even if it's
> >> >> >>> not necessarily the best approach).
> >> >> >>>
> >> >> >>
> >> >> >> Original post asked for either change of behavior or
> >> >> >> documentation, I failed to find the precise documentation, care
> >> >> >> pointing out where exactly things are described in the manual?
> >> >
> >> > http://caml.inria.fr/pub/docs/manual-ocaml/comp.html#sec263
> >> > describes how .mli and .ml are handled by the compiler (and when
> >> > .cmi is generated or checked against) and the description of -I in
> >> > http://caml.inria.fr/pub/docs/manual-ocaml/comp.html#sec264
> >> > explains that -I only adds search directories for compiled files,
> >> > not source files.
> >>
> >> Thanks, but the manual is completely silent on WHERE it looks for
> >> those files. The issue is not trivial as there are 3 options I can
> >> readily come up with:
> >>      a. current working directory
> >>      b. base directory of -o argument
> >>      c. a set of -I directories
> >>      d. directory where file to be compiled lives
> >>
> >> It looks as if option d. is in effect, but nowhere it is spelled out.
> >
> > Hmm - to my taste the silence says everything required! Options b and
> > c are completely illogical (b would involve inferring an input
> > directory from an output directory and option c contradicts something
> > the manual does state about what -I means). Option a would be
> > surprising behaviour and to my mind is contradicted by the use of "x"
> > in italics 8.1 which to me quite reasonably reads as "change the .ml
> > to .mli" and so include the directory, if there is one. To expect the
> > compiler to look for ./foo.mli when you specified bar/foo.ml would
> > mean you'd changed "x".
> >
> 
> As outlined in the original message, suppose you have the same interface
> but several different implementations (selected during the package
> configuration step for instance), let's call the module Mod.
> 
> Under option d. variants (living in different directories) would each have
> to carry the _same_ mod.mli file in the container directory just to
> satisfy the compilers discovery logic.
> 
> srctree/var1/mod.{ml,mli}
> srctree/var2/mod.{ml,mli}
> 
> instead of potential
> 
> srctree/mod.mli srctree/var1/mod.ml srctree/var2/mod.ml

Yes, I get that - this is starting to feel mutually recursive. As it concerns you hugely, looking again at your original message:

a) Yes, the compiler does expect the .ml and .mli files to be in the same directory
b) Yes, this behaviour is specified in the manual, possibly too mathematically for your tastes, and perhaps benefitting from a cross-reference/extra sentence in section 2.5 to the compiler driver's documentation.
c) No, the compiler does not force you to put .mli files with the .ml files in your use case - it has existing tools which can just about facilitate the layout you're after (see below). They could be improved, though.
d) Lifting the "restriction", for example by allowing -I to search for .mli files, poses a large backwards-compatibility risk.

Of the options I'd already specified, were any of:

a) Add a new command line parameter to make ocamlc/ocamlopt pretend that it found a .mli file with the .ml file (and so use the -I directories to find the .cmi)
b) Abuse the -intf-suffix parameter to achieve the same effect as option a 
c) Put a dummy/empty .mli (not the actual one) in each directory to achieve the same thing

fundamentally unsuitable? You did eliminate the fourth option, which was just to delete the auto-generated .cmi file as with -o you can make it overwrite the actual .cmi file. I'm still puzzled as to why none of those other options yields a solution and the only way to you is a breaking change to the compiler driver or very pedantic updates to the documentation?


David