[Caml-list] Interface(.mli) location

[Caml-list] Interface(.mli) location

[moosotc]

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

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

[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

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

[Gerd Stolpmann]

[-- Attachment #1: Type: text/plain, Size: 4030 bytes --]

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
------------------------------------------------------------


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[moosotc]

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.

[..snip..]

-- 
mailto:moosotc@gmail.com

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

[David Allsopp]

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.

Gerd is right that it's not so great that the compiler ignores d/a.cmi and still generates the automatic a.cmi (though I'm not convinced it's an error, personally). The automatic .cmi files are a pain in other areas (it's a nuisance in build systems, as it makes parallelisation harder). I'd have preferred to have something like ocamlc -ci a.ml being roughly equivalent to:

$ ocamlc -i a.ml > a.mli
$ ocamlc -c a.mli
$ rm a.mli

and the "gotcha" of forgetting to run ocamlc -ci a.ml being the first lesson in always producing .mli files, but it's a bit late for changes that :o)


David 

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

[moosotc]

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.

>
> Gerd is right that it's not so great that the compiler ignores d/a.cmi
> and still generates the automatic a.cmi (though I'm not convinced it's
> an error, personally). The automatic .cmi files are a pain in other
> areas (it's a nuisance in build systems, as it makes parallelisation
> harder). I'd have preferred to have something like ocamlc -ci a.ml
> being roughly equivalent to:
>
> $ ocamlc -i a.ml > a.mli
> $ ocamlc -c a.mli
> $ rm a.mli
>
> and the "gotcha" of forgetting to run ocamlc -ci a.ml being the first
> lesson in always producing .mli files, but it's a bit late for changes
> that :o)
>
>
> David 
>

-- 
mailto:moosotc@gmail.com

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

[David Allsopp]

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)


David

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

[moosotc]

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?

>
>
> David

-- 
mailto:moosotc@gmail.com

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

[David Allsopp]

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?

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).


David

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

[SF Markus Elfring]

> I think the use-case is too niche to justify breaking backwards compatibility.

Do you care for development challenges around parallel software builds?

Would you like to consider other possibilities?


> That's potentially a very subtle way to break someone else's existing build system.

How do you think about the application of an extra environment variable
(or a command line parameter) which specifies the preferred directory
for the storage of compiled interface descriptions?


> The existing behaviour is precisely documented in the manual

I find that there is still room for interpretation.


> (even if it's not necessarily the best approach).

Are you looking for corresponding software extensions?

Regards,
Markus

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

[SF Markus Elfring]

> a) Delete ./a.cmi as part of your build procedure.

Can this design option trigger difficulties in your file system configuration?


>    This isn't ideal, though, because you lose the type-checking against d/a.cmi

Would you like to explain this conclusion a bit more?


> 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)

I would find such a command parameter also useful.
Will any more fine-tuning be considered for the safer handling
of interface descriptions and corresponding implementations?

Regards,
Markus

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

[moosotc]

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?
>
> 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?

-- 
mailto:moosotc@gmail.com

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

[moosotc]

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?

Also, consider this:

[malc@linmac2 mli]$ cat repro2.sh; sh repro2.sh
#!/bin/sh
set -x
rm -fr a* d o

mkdir -p o d

echo 'type a = int and b = int' >a.ml
echo 'type a = int' >d/a.mli

ocamlc -c -o o/a.cmi d/a.mli
md5sum o/a.cmi
ocamlc -c -o o/a.cmo a.ml
md5sum o/a.cmi
+ rm -fr a.ml d o
+ mkdir -p o d
+ echo 'type a = int and b = int'
+ echo 'type a = int'
+ ocamlc -c -o o/a.cmi d/a.mli
+ md5sum o/a.cmi
dddf074fdfa94cad226485870c617116  o/a.cmi
+ ocamlc -c -o o/a.cmo a.ml
+ md5sum o/a.cmi
bc44d889df40c61e43dbd94535ffd614  o/a.cmi

IOW compilation of a.ml will override .cmi produced by compilation of
a.mli, the point, I guess, is that there's a lot to specify here.

-- 
mailto:moosotc@gmail.com

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

[moosotc]

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?
>
> Also, consider this:
>

Better this (with safety nets in form of added -Is)

[malc@linmac2 mli]$ cat repro2.sh; sh repro2.sh
#!/bin/sh
set -x
rm -fr a* d o

mkdir -p o d

echo 'type a = int and b = int' >a.ml
echo 'type a = int' >d/a.mli

ocamlc -c -o o/a.cmi d/a.mli
md5sum o/a.cmi
ocamlc -I o -I d -c -o o/a.cmo a.ml
md5sum o/a.cmi
+ rm -fr 'a*' d o
+ mkdir -p o d
+ echo 'type a = int and b = int'
+ echo 'type a = int'
+ ocamlc -c -o o/a.cmi d/a.mli
+ md5sum o/a.cmi
dddf074fdfa94cad226485870c617116  o/a.cmi
+ ocamlc -I o -I d -c -o o/a.cmo a.ml
+ md5sum o/a.cmi
bc44d889df40c61e43dbd94535ffd614  o/a.cmi

[..snip..]

>
> IOW compilation of a.ml will override .cmi produced by compilation of
> a.mli, the point, I guess, is that there's a lot to specify here.

-- 
mailto:moosotc@gmail.com

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

[David Allsopp]

SF Markus Elfring wrote:
> 
> > I think the use-case is too niche to justify breaking backwards
> > compatibility.
> 
> Do you care for development challenges around parallel software builds?
> 
> Would you like to consider other possibilities?

I don't follow you here, I'm afraid. My point was I think it better to add something new which fixes this, rather than risk breaking other things by changing existing behaviour.

> > That's potentially a very subtle way to break someone else's existing
> build system.
> 
> How do you think about the application of an extra environment variable
> (or a command line parameter) which specifies the preferred directory for
> the storage of compiled interface descriptions?

What does that solve?

> > The existing behaviour is precisely documented in the manual
> 
> I find that there is still room for interpretation.

What kind of room, though? The only ambiguity I can see is precisely how you handle references on the command line including directory names.

> > (even if it's not necessarily the best approach).
> 
> Are you looking for corresponding software extensions?

Afraid I don't follow that.


David

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

[David Allsopp]

SF Markus Elfring wrote:
> > a) Delete ./a.cmi as part of your build procedure.
> 
> Can this design option trigger difficulties in your file system
> configuration?

What sort of difficulties do you mean?

> >    This isn't ideal, though, because you lose the type-checking
> > against d/a.cmi
> 
> Would you like to explain this conclusion a bit more?
d/a.cmi may constrain values defined in ./a.ml and you won't get the type-checking this way. For example, you could have [val foo: int] in d/a.mli but [let foo = "bar"] in ./a.ml and compiling this way you'll only spot the error later on when trying to link.

> > 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)
> 
> I would find such a command parameter also useful.
> Will any more fine-tuning be considered for the safer handling of
> interface descriptions and corresponding implementations?

I was just floating ideas - if it's actually useful, raise a Mantis PR!


David

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

[SF Markus Elfring]

>> How do you think about the application of an extra environment variable
>> (or a command line parameter) which specifies the preferred directory for
>> the storage of compiled interface descriptions?
> 
> What does that solve?

I am looking for further possibilities to improve the software situation
in ways similar to your suggestions.


> The only ambiguity I can see is precisely how you handle references
> on the command line including directory names.

Can directory preferences become clearer?

Regards,
Markus

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

[David Allsopp]

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.

> > Also, consider this:
> >
> 
> Better this (with safety nets in form of added -Is)
> 
> [malc@linmac2 mli]$ cat repro2.sh; sh repro2.sh
> #!/bin/sh
> set -x
> rm -fr a* d o
> 
> mkdir -p o d
> 
> echo 'type a = int and b = int' >a.ml
> echo 'type a = int' >d/a.mli
> 
> ocamlc -c -o o/a.cmi d/a.mli
> md5sum o/a.cmi
> ocamlc -I o -I d -c -o o/a.cmo a.ml
> md5sum o/a.cmi
> + rm -fr 'a*' d o
> + mkdir -p o d
> + echo 'type a = int and b = int'
> + echo 'type a = int'
> + ocamlc -c -o o/a.cmi d/a.mli
> + md5sum o/a.cmi
> dddf074fdfa94cad226485870c617116  o/a.cmi
> + ocamlc -I o -I d -c -o o/a.cmo a.ml
> + md5sum o/a.cmi
> bc44d889df40c61e43dbd94535ffd614  o/a.cmi
> 
> [..snip..]

This, again, is just the compiler acting exacting as it says it should! When you compile o/a.ml, ocamlc looks for ./a.mli and because it doesn't find it, it overwrites o/a.cmi (because of the -o switch).


David 

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

[SF Markus Elfring]

>>> a) Delete ./a.cmi as part of your build procedure.
>>
>> Can this design option trigger difficulties in your file system
>> configuration?
> 
> What sort of difficulties do you mean?

Do software build systems track the existence of such a generated file?

Are you also concerned about a harder parallelisation there?


> d/a.cmi may constrain values defined in ./a.ml and you won't get
> the type-checking this way.

I would usually expect that these interface descriptions should be
kept consistent to some degree.


> I was just floating ideas - if it's actually useful, raise a Mantis PR!

Will another official bug report or feature request help to improve
the discussed situation?

Regards,
Markus

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

[David Allsopp]

SF Markus Elfring wrote:
> >>> a) Delete ./a.cmi as part of your build procedure.
> >>
> >> Can this design option trigger difficulties in your file system
> >> configuration?
> >
> > What sort of difficulties do you mean?
> 
> Do software build systems track the existence of such a generated file?
>
> Are you also concerned about a harder parallelisation there?
>
> > d/a.cmi may constrain values defined in ./a.ml and you won't get the
> > type-checking this way.
> 
> I would usually expect that these interface descriptions should be kept
> consistent to some degree.

Well yes, except that the compiler has two ways of interpreting an .ml file. Consistency would be maintained in either scenario - when there's a .ml and a .mli, the compiler will ensure that the interface of the Foo.ml and Foo.cmi unify, and you'll get a type error if they don't. Alternatively, if you don't have Foo.mli (so Foo.cmi and Foo.cmo are both generated) and you later try to link Foo.cmo with a module which expected it to comply with a different .cmi interface, you will get an "inconsistent assumptions about module Foo" link error (which admittedly would be very confusing, as that usually implies you have stale object files somewhere, not a broken build system). 

> > I was just floating ideas - if it's actually useful, raise a Mantis PR!
> 
> Will another official bug report or feature request help to improve the
> discussed situation?

It's just the next step if a change wants to made (or alternately coding up a suggestion and making a pull request on GitHub). I can certainly see that something along the lines of the -no-cmi option I suggest could be a useful addition, and it's in keeping with options like -impl, -intf and -intf-suffix, for example. But I'm just an observer :o)


David

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

[David Allsopp]

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...


David 

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

[moosotc]

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.

>
>> > Also, consider this:
>> >
>> 
>> Better this (with safety nets in form of added -Is)
>> 
>> [malc@linmac2 mli]$ cat repro2.sh; sh repro2.sh
>> #!/bin/sh
>> set -x
>> rm -fr a* d o
>> 
>> mkdir -p o d
>> 
>> echo 'type a = int and b = int' >a.ml
>> echo 'type a = int' >d/a.mli
>> 
>> ocamlc -c -o o/a.cmi d/a.mli
>> md5sum o/a.cmi
>> ocamlc -I o -I d -c -o o/a.cmo a.ml
>> md5sum o/a.cmi
>> + rm -fr 'a*' d o
>> + mkdir -p o d
>> + echo 'type a = int and b = int'
>> + echo 'type a = int'
>> + ocamlc -c -o o/a.cmi d/a.mli
>> + md5sum o/a.cmi
>> dddf074fdfa94cad226485870c617116  o/a.cmi
>> + ocamlc -I o -I d -c -o o/a.cmo a.ml
>> + md5sum o/a.cmi
>> bc44d889df40c61e43dbd94535ffd614  o/a.cmi
>> 
>> [..snip..]
>
> This, again, is just the compiler acting exacting as it says it
> should! When you compile o/a.ml, ocamlc looks for ./a.mli and because
> it doesn't find it, it overwrites o/a.cmi (because of the -o switch).

But .mli does exist in -I d and .cmi in -I o...

I suppose arguing all of this is pointless, but I do stand by my
assertion that his behavior is underspecified.

-- 
mailto:moosotc@gmail.com

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

[moosotc]

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)

-- 
mailto:moosotc@gmail.com

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

[David Allsopp]

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". 


David

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

[David Allsopp]

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

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

[moosotc]

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

-- 
mailto:moosotc@gmail.com

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

[David Allsopp]

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

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

[moosotc]

David Allsopp <dra-news@metastack.com> writes:

> moosotc@gmail.com wrote:
>> David Allsopp <dra-news@metastack.com> writes:
[..snip..]

>> 
>> 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)

That'd work.

> b) Abuse the -intf-suffix parameter to achieve the same effect as option a 

Sorry, haven't tried that.

> c) Put a dummy/empty .mli (not the actual one) in each directory to
> achieve the same thing
>

This does work. Thanks.

> 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?
>

c. Which does work is not "fundamentally unsuitable" it's just:
   a) not aesthetic
   b) wastes an inode/repository entry

-- 
mailto:moosotc@gmail.com