[Caml-list] ocamldep & compilation units

[Caml-list] ocamldep & compilation units

[Remco Vermeulen]

Hi,

I’m kind of stuck on the following situation.

foo.ml:
	...
 	module BAR = struct
 		…

		let x () = ...
	end
	...
	end

bar.ml:
       …
       let y () = …

baz.ml:
	open Foo
	...
	BAR.x ()
        …
	Bar.y ()

ocamldep -modules baz.ml, as used by Omake, returns baz.ml: BAR bar.
The manual of ocamldep states that the -modules option returns the compilation units referenced in the source file.
But shouldn’t, in this situation, only Bar be a compilation unit?

In the current situation, Omake adds the compilation unit BAR to the dependencies of baz.cm(o|x),
meaning that it will search for the file bAR.ml to satisfy the dependency.
This has the unfortunate effect of using bar.ml on a case-insensitive filesystem (the default on OSX) resulting in the error:
"Wrong file naming: bar.cmi contains the compiled interface for Bar when BAR was expected”

So my question is. is BAR in the above example correctly identified as a compilation unit by ocamldep?

Cheers,
Remco 

Re: [Caml-list] ocamldep & compilation units

[Gerd Stolpmann]

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

Am Freitag, den 02.01.2015, 15:03 +0100 schrieb Remco Vermeulen:
> So my question is. is BAR in the above example correctly identified as a compilation unit by ocamldep?

The syntax doesn't allow an unambiguous identification, so ocamldep
needs to take into account that BAR is a compilation unit. It doesn't
follow "open" when doing this, and I guess this is the point that
confuses you.

The problem is that "ocamldep -modules" by definition can only analyze a
single module. The output is imprecise, however, and possible
inter-module effects are not taken into account (among other things). A
precise output would list BAR with the exception that it might be
shadowed by Foo.

But imagine now we had the information with this degree of detail. As
omake wants to figure out the dependencies it would have to solve a
puzzle. In your case it is easily to solve, but in practice there are
often several "open" directives, and in this case you don't even know
whether "open Foo" opens a compilation unit. I am not sure whether a
well-performing algorithm even exists (did anybody tackle this
problem?).

The workaround is to use naming schemes that allow you to clearly
distinguish between local modules and compilation unit (e.g. all your
local modules have 1-3 characters, and all compilation units have longer
names).

Gerd
-- 
------------------------------------------------------------
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] ocamldep & compilation units

[Remco Vermeulen]

> 
> On 02 Jan 2015, at 19:11, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> 
> Am Freitag, den 02.01.2015, 15:03 +0100 schrieb Remco Vermeulen:
>> So my question is. is BAR in the above example correctly identified as a compilation unit by ocamldep?
> 
> The syntax doesn't allow an unambiguous identification, so ocamldep
> needs to take into account that BAR is a compilation unit. It doesn't
> follow "open" when doing this, and I guess this is the point that
> confuses you.
What confused me is that the documentation says ocamldep -modules returns the module names of compilation units
referenced in the source file, and then includes local modules when the “parent” module is implicitly qualified through open.
When the local module is referenced explicitly (i.e, fully qualified), it is not included, which is inconsistent.
> 
> The problem is that "ocamldep -modules" by definition can only analyze a
> single module. The output is imprecise, however, and possible
> inter-module effects are not taken into account (among other things). A
> precise output would list BAR with the exception that it might be
> shadowed by Foo.
Perhaps a note should be added to the documentation of ocamldep about this.
> 
> But imagine now we had the information with this degree of detail. As
> omake wants to figure out the dependencies it would have to solve a
> puzzle. In your case it is easily to solve, but in practice there are
> often several "open" directives, and in this case you don't even know
> whether "open Foo" opens a compilation unit. I am not sure whether a
> well-performing algorithm even exists (did anybody tackle this
> problem?).
> 
> The workaround is to use naming schemes that allow you to clearly
> distinguish between local modules and compilation unit (e.g. all your
> local modules have 1-3 characters, and all compilation units have longer
> names).
This is not really an option, since this happens in an 3rd party library.
It seems that patching the omake ocaml scanner, to not rely on the -modules option,
seems to be the way to go as this is not trivial to handle in ocamldep.

Thanks for your clarification!

Cheers,
Remco

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

Re: [Caml-list] ocamldep & compilation units

[Gabriel Scherer]

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

ocamldep is approximative by design (providing a correct list of
dependencies requires interleaving type-checking and dependency
computations, a very different *compiler* design that would require an
important amount of work). The easiest way out in the current state of
things is to have an option in build systems to remove spurious
dependencies by hand (they're quite rare in practice). ocamlbuild for
example has a (non_dependency "baz" "BAR") that you would use in your
situation. If Omake lacks such a capability, I think the best step forward
would be to add it (instead of trying to come up with different heuristics
than "ocamldep -modules").

On Sat, Jan 3, 2015 at 11:52 AM, Remco Vermeulen <r.vermeulen@vu.nl> wrote:

> >
> > On 02 Jan 2015, at 19:11, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> >
> > Am Freitag, den 02.01.2015, 15:03 +0100 schrieb Remco Vermeulen:
> >> So my question is. is BAR in the above example correctly identified as
> a compilation unit by ocamldep?
> >
> > The syntax doesn't allow an unambiguous identification, so ocamldep
> > needs to take into account that BAR is a compilation unit. It doesn't
> > follow "open" when doing this, and I guess this is the point that
> > confuses you.
> What confused me is that the documentation says ocamldep -modules returns
> the module names of compilation units
> referenced in the source file, and then includes local modules when the
> “parent” module is implicitly qualified through open.
> When the local module is referenced explicitly (i.e, fully qualified), it
> is not included, which is inconsistent.
> >
> > The problem is that "ocamldep -modules" by definition can only analyze a
> > single module. The output is imprecise, however, and possible
> > inter-module effects are not taken into account (among other things). A
> > precise output would list BAR with the exception that it might be
> > shadowed by Foo.
> Perhaps a note should be added to the documentation of ocamldep about this.
> >
> > But imagine now we had the information with this degree of detail. As
> > omake wants to figure out the dependencies it would have to solve a
> > puzzle. In your case it is easily to solve, but in practice there are
> > often several "open" directives, and in this case you don't even know
> > whether "open Foo" opens a compilation unit. I am not sure whether a
> > well-performing algorithm even exists (did anybody tackle this
> > problem?).
> >
> > The workaround is to use naming schemes that allow you to clearly
> > distinguish between local modules and compilation unit (e.g. all your
> > local modules have 1-3 characters, and all compilation units have longer
> > names).
> This is not really an option, since this happens in an 3rd party library.
> It seems that patching the omake ocaml scanner, to not rely on the
> -modules option,
> seems to be the way to go as this is not trivial to handle in ocamldep.
>
> Thanks for your clarification!
>
> Cheers,
> Remco
>
> >
> > Gerd
> > --
> > ------------------------------------------------------------
> > 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
> > ------------------------------------------------------------
>
> --
> 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
>

[-- Attachment #2: Type: text/html, Size: 4909 bytes --]

Re: [Caml-list] ocamldep & compilation units

[Xavier Leroy]

On 02/01/15 15:03, Remco Vermeulen wrote:
> baz.ml:
> 	open Foo
> 	...
> 	BAR.x ()
>         …
> 	Bar.y ()
> 
> ocamldep -modules baz.ml, as used by Omake, returns baz.ml: BAR bar.

To add to the useful answers already given, another way to work around
this issue is to use explicit qualification for BAR:

 	open Foo
 	...
 	Foo.BAR.x ()
         …
 	Bar.y ()

That will prevent ocamldep from mistaking BAR for a compilation unit.

Gerd Stolpmann adds:

> But imagine now we had the information with this degree of detail. As
> omake wants to figure out the dependencies it would have to solve a
> puzzle. In your case it is easily to solve, but in practice there are
> often several "open" directives, and in this case you don't even know
> whether "open Foo" opens a compilation unit. I am not sure whether a
> well-performing algorithm even exists (did anybody tackle this
> problem?).

Matthias Blume showed a NP-completeness result for a closely-related problem:

Matthias Blume: Dependency analysis for Standard ML. ACM
Trans. Program. Lang. Syst. 21(4): 790-812 (1999)

- Xavier Leroy