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