RE: [Caml-list] Development status of the dependency generator for OCaml

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

Markus Elfring wrote:
> Hello,
> 
> I took a closer look at data which the tool “ocamldep” can provide.
> 
> 
> * Compiled module interfaces (CMI files) do not depend on interface
>   descriptions (MLI files) there.
>   Is such dependency information interpreted as an optional detail?

It surprises me to find that ocamldep -all foo.mli doesn't generate `foo.cmi: foo.mli`, but including these dependencies in the output of ocamldep seems of limited use to me - at some point you need a rule to compile the file, e.g.

%.cmi: %.mli
	ocamlc -c $^

and ocamldep will *never* generate that.

> * Compiled modules do also not depend on OCaml sources (ML files) there.
>   Some of the generated make specifications indicate only a dependency on
>   a single compiled module interface.

You can get the .ml (and .o files) included by using ocamldep -all

What are you regarding as erroneous about the entries with "only a dependency on a single compiled module interface" (for bytecode, that sounds correct to me).

> Do you expect that dependency data should be exported completely?

Depends on your definition of completely - the -all flag seems to do most of what you're after, and the part which is missing looks to be of limited value.

> Another view:
> It is usually expected that some dependencies can be handled by implicit
> make rules. So I imagine that the provided data should only contain
> extensions for the desired software build rules.
> https://www.gnu.org/software/make/manual/html_node/Multiple-Rules.html
> 
> It seems that a bit of data is written too much so far according to this
> usage.
> How would you like to improve the software situation further?

You mean that you'd like simple cases eliminated? For example:

foo.cmi:
foo.cmo: foo.cmi

should simply not be printed, and be assumed to work with implicit rules? When one takes the maintenance burden into account, I'm not sure I'd see that as an improvement...


David