Original bug ID: 4047
Reporter: jyh
Assigned to: @xavierleroy
Status: closed (set by @xavierleroy on 2006-08-31T09:51:45Z)
Resolution: fixed
Priority: normal
Severity: feature
Version: 3.09.2
Category: ~DO NOT USE (was: OCaml general)
Monitored by: jyh nogin @alainfrisch

Bug description

Summary: we suggest a -modules option to ocamldep to prevent information loss. A patch is attached.

ocamldep is very good at computing the free module names of a source file. In its second phase, ocamldep tries to match each module name with a file. The second phase is lossy--if ocamldep can't find a file with a .mli or .ml suffix, it gives up. For example, if the dependency is on a .mly file, and ocamlyacc hasn't been run yet, ocamldep will omit the dependency.

The problem is that ocamldep doesn't have enough information. What matters is that a dependency can be built, not that it is already built. Adding heuristics to ocamldep (for example, adding the ability to recognize .mly files) doesn't help in general. In some projects, including mine, even the .mly files are generated.

In OMake, the build order is in general nondeterminisic, and sloppy dependencies cause subtle bugs that can be extremely hard to debug and reproduce. However, given a set of free module names, it is easy for OMake to match them to targets, even if the files don't exist yet, because OMake has access to the entire build tree. Dependencies can be accurate, but it requires cooperation between ocamldep and the build system.

We propose a simple solution. Add a -modules option that tells ocamldep to print the raw set of free module names, without loss.

The change to ocamldep is minor. Given the -modules option, ocamldep produces output in the following form.

<sourcefile>:
    <free-module-names>

So if foo.ml depends on Fee and Fum and List, the output might be:

foo.ml:
    Fee
    Fum
    List

ocamldep is really very good at scanning a file for free module names. We very much don't want to implement something custom -- ocamldep is definitely better. Adding this feature provides a quite astonishing improvement in build reliability and transparency -- we really want it!

Additional information

See recent discussions on the OMake mailing list (on this topic:)
http://lists.metaprl.org/pipermail/omake/2006-June/001076.html
http://lists.metaprl.org/pipermail/omake/2006-June/001102.html

Some related issues in this forum:
#3162
#3190
#3764
#3725

The OMake code making use of ocamldep -modules is in the OCaml.om file.
http://svn.metaprl.org/viewcvs/mojave/omake-branches/0.9.8.ocamldep/lib/build/OCaml.om?rev=9309&view=log

The interesting part is the following call, which determines the filename associated with a .cmi file, even if the .cmi does not already exist.
$(find-targets-in-path-optional $(OCAMLINCLUDES), $(cmideps))

The name of the -modules option and the format of the output don't matter much, as long as the output is unambiguous and relatively easy to parse.

For now, our OMake source tree contains the bytecode for a ocamldep-omake. This file is derived from your ocamldep source by compiling with the patch. Please let me know if this is unacceptable.

File attachments

• ocamldep.patch