Re: [Caml-list] Forcing OCamlbuild to compile a file before another

[Gabriel Scherer <gabriel.scherer@gmail.com>]

I thought a bit more about this and here is a plan that seems
reasonable (I fact-checked it with Pierre Chambart and Benoît Vaugon)
and does not require changing ocamldep.

1) add a notion of foo.mlalias files with content of the form

  M := Foo_M
  Z := Bar_Z
  ...

  with a rule .mlalias -> .cmi that generates the .ml and compiles it
with -no-alias-deps (note that by design it never has any dependency)

2) add the following rules in the code that computes dependencies from
the output of ocamldep:
      if the module depends on Foo (which is the name of an alias
file) and M, and (M := Bar) is in foo.mlalias, then also add Bar as a
dependency

This should solve the problem of false cyclic dependencies caused by
using short names inside the project itself.


Remarks:

- I considered, instead of a .mlalias file with a specific syntax,
allowing to tag any .ml file as an alias-giving files; that makes the
system more complex, because the alias-giving files may contain other
OCaml statements than alias definitions, and thus have some
dependencies (and we don't want to get in the business of trying to
guess which modules are just aliases or real dependencies, or having
to inspect .cmi files after-the-fact to rebuild the aliasing map). The
downside is that people with an existing -no-alias-deps scheme
suddenly willing to use ocamlbuild would have to rewrite some stuff
first. (The other direction can be made automatic by a .mlalias ->
.ml.inferred rule)

- The restriction that the .mlalias file only contains module aliases
and not other things you might want to have in a prelude/header is not
really a restriction, as "include Foo" (where Foo is the name of the
aliases-defining module) should work. I have not tested it, though.

- It might be possible to implement this at the plugin level. The
.mlalias rule could be proposed as a plugin. I'm less confident about
the dependency-mangling logic, but the idea would be to overload the
existing ".ml -> .ml.depends" rule to change the .ml.depends result
(instead of its interpretation by ocamlbuild as I had in mind above).

On Wed, Feb 4, 2015 at 2:18 PM, Dario Teixeira
<dario.teixeira@nleyten.com> wrote:
> Hello again Gabriel,
>
>> I haven't given much thought to it yet, but here would a sketchy idea
>> of how to better support -no-alias-deps in OCamlbuild:
>>
>> ocamldep) extend ocamldep with a new -paths (as an extension over
>> -modules) that returns not just the modules M appearing at the
>> beginning of paths in source files, but the full module-longident (eg.
>> M.Foo.Bar if you access the value M.Foo.Bar.baz or constructor
>> M.Foo.Bar.Foobar)
>>
>> ocamlbuild) use ocamldep -modules (this happens in
>> ocaml_utils.ml:read_path_dependencies), and for a non-singleton path
>> of the form Foo.Bar, first type-check the compilation unit Foo, then
>> inspect the .cmi to know whether Bar is defined as a module alias of
>> Foo, and in that case depend on the aliased compilation unit
>>
>> (This should be done as a modification to the tool itself rather than
>> a plugin, I think.)
>
>
> Yes, I agree that all these tweaks to support -no-alias-deps should
> ideally be part of OCamlbuild+OCamldep and work out-of-the-box.
> Moreover, the modifications you suggest are in line with what I'm
> planning to implement as a myocamlbuild plugin (I'll have to do it
> as a plugin because I don't want to wait for a future OCaml release).
>
> The table below lists the dependencies of my dummy project, as computed
> by the alias-oblivious OCamldep and what they actually are:
>
>                 OCamldep:                       Actual:
>
> Foo.ml:         Foo_a, Foo_b, Foo_c             (none)
> Foo_a.ml:       Foo                             Foo
> Foo_b.ml:       Foo, A                          Foo, Foo_a
> Foo_c.ml:       Foo, A, B                       Foo, Foo_a, Foo_b
>
> So basically I'll postprocess the output of OCamldep: whenever it finds
> that a module depends both on Foo and on an alias declared in Foo, then
> I'll replace the alias with the actual module.  In addition, all of Foo's
> dependencies must be cleared as well (it's more practical to just invoke
> non_dependency for this purpose).
>
> My initial idea was to manipulate the dependency graph instead of resorting
> to postprocessing OCamldep's output.  Alas, as you made clear on your other
> message, OCamlbuild does not actually construct a dependency graph before
> the "real" compilation starts.
>
> Thanks again for your time!
> Kind regards,
> Dario Teixeira
>
>
>
> --
> 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