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

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

> And, I presume, also remove M from the module's dependency list, right?

That's not correct in the general case. Consider for example:

  bar.ml: ...

  long_bar.ml: ...

  foo.mlalias:
    Bar := Long_bar

  example.ml:
    include Bar
    open Foo
    include Bar

On the contrary, *over*-approximating the dependencies (what happens
in the sane situations where M really isn't a dependency, only its
long form) should be harmless and is already done by ocamldep anyway
(as soon as a you open a module that has submodules and use them, they
get listed as extraneous dependencies).

> Which leads me to the question: is it feasible to do the postprocessing
> in OCamlbuild, or will I have to write an external script that does
> the postprocessing and gets invoked by setting Options.ocamldep?

You can add new rules in a plugin (eg. one for .mlalias files), and
override existing rules by playing with priority levels (which is a
kind of dubious business but well...). If you override the ".ml ->
.ml.depends" rule (see "ocaml dependencies ml" in
ocamlbuild/ocaml_specific.ml, you can replace the current ocamldep
invocation by a command that invokes ocamldep and does the
preprocessing you want.
I suspect that the easier route depends on how you want to specify the
logic of which dependencies to remove. If you're happy with listing
manually the aliases of your particular project, then just giving them
to an external script would probably be easier (sitting inside
OCamlbuild don't bring you much because you don't need access to its
information) -- note that you can override the ocamldep command from
inside myocamlbuild.ml. If you want a somewhat generic mechanism like
recognizing .mlalias files, then the ocamlbuild codebase may be of
help.

On Wed, Feb 4, 2015 at 5:15 PM, Dario Teixeira
<dario.teixeira@nleyten.com> wrote:
> Hi,
>
>> 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)
>
>
> This seems reasonable.  In a sense, modules like foo.ml whose contents
> are just a list of aliases are already "special" in a way, and this
> convention emphasises that.  Moreover, it has an added documentation
> advantage: simply by listing mlalias files a newcomer may familiarise
> themselves with the module aliases used in a project.
>
>
>> 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
>
>
> And, I presume, also remove M from the module's dependency list, right?
>
>
>> - 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)
>
>
> Yeah, I see no need to overcomplicate this.
>
>
>> (...)
>> - 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).
>
>
> It would be of course nice if all this logic made its way into 4.03
> or 4.02.2 as part of OCamlbuild's builtins.  Regardless, from my
> perspective of someone who's not familiar with OCamlbuild's code
> base and inner workings, I think the most straightforward interim
> solution will be along the lines of what I described in my previous
> message: write a plugin that postprocesses OCamldep's output.  Which
> leads me to the question: is it feasible to do the postprocessing
> in OCamlbuild, or will I have to write an external script that does
> the postprocessing and gets invoked by setting Options.ocamldep?
>
>
> 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