Hi Michael,


> One can of cause discuss if it is good style to have circular dependencies
> between module implementations. One can also discuss if it is the job of a
> build tool to enforce such policies, or if a build tool should reduce the
> set of valid programs.


I think there is a misconception here. The behavior of the compiler in
presence of such circular dependencies is undefined. The current
implementation happens to allow them, but this does not mean that they are
"valid programs".

The OCaml language specification is admittedly not very detailed on the
relation between OCaml language concepts and filesystem-level files, but
you can find a fairly clear explanation of it here:
  6.12 Compilation units
  http://caml.inria.fr/pub/docs/manual-ocaml/compunit.html

Compilation units bridge the module system and the separate compilation
> system. A compilation unit is composed of two parts: an interface and an
> implementation. The interface contains a sequence of specifications, just
> as the inside of a sig … end signature expression. The implementation
> contains a sequence of definitions and expressions, just as the inside of a
> struct … end module expression. A compilation unit also has a name
> unit-name, derived from the names of the files containing the interface
> and the implementation (see chapter 8 for more details).
>
[...]
>
A compilation unit can refer to other compilation units by their names, as
> if they were regular modules. [...]
>

In other words, a compilation unit is *a pair* of a .ml file and a .mli
file (the latter being optional), and dependencies should be understood at
that level.

I understand that there is a lot of working code that breaks this model (I
personally find it unfortunate), and that large users of OCaml have been
taking liberties with the model as they are familiar with the
implementation (eg. moving .cmi files around independently from where the
compiled implementations are located).

This is all fine, but I'm not personally interested in supporting complex
unspecified behavior in a build tool (ocamlbuild) that I think has other,
more pressing usability issues to adress.

I think there are many cases, where two modules are just handling different
> aspects of a common complex data structure (in this case a C AST) and there
> is no natural ordering between them.
>

The solution I would recommend is to split the shared definitions in a
shared module they both depend on.

On Sat, Jul 9, 2016 at 8:53 AM, Soegtrop, Michael <
michael.soegtrop@intel.com> wrote:

> Dear OCaml Users and Developers,
>
>
>
> It has been discussed a few times on the list, that ocambuild treats .mli
> and .ml files as one regarding dependencies (unlike ocamldep), so that
> projects which have dependencies of the type A.ml depends on B.mli and B.ml
> depends on A.mli, cannot be built with ocamlbuild, although they can be
> built by other means.
>
>
>
> One can of cause discuss if it is good style to have circular dependencies
> between module implementations. One can also discuss if it is the job of a
> build tool to enforce such policies, or if a build tool should reduce the
> set of valid programs.
>
>
>
> Let me describe the issue which gives me headaches right now. I am working
> on a tool doing certain analysis on C programs. In this tool I have a
> module handling types and a module handling constant folding. Both have a
> circular dependency in their implementation. Look e.g. at this case:
>
>
>
> sizeof(int[3*4])*2
>
>
>
> The type handling module needs to call the constant folding module to get
> the value of 3*4. The constant folding module needs to call the type module
> for handling the sizeof. There are no easy ways around the circular
> dependency here. One way would be to have a mutable value field in my AST
> and write the folded values to the AST while doing constant folding, so
> that the type module can access the value when it needs it. I have my
> doubts that this is nicer than living with the circular dependency. Anyway
> I want to be able to decide this and not be forced to a solution by a build
> tool. I think there are many cases, where two modules are just handling
> different aspects of a common complex data structure (in this case a C AST)
> and there is no natural ordering between them.
>
>
>
> As a result I would recommend to support in ocamlbuild the same dependency
> model as ocamldep has (things are fine as long as .mli files don’t have
> circular dependencies).
>
>
>
> The only way I see right now to get my job done is to discard ocamlbuild
> and use OcamlMakefile. Since I use menhir –infer, I first have to modify
> OcamlMakefile to handle dependencies in way menhir can live with.
>
>
>
> Best regards,
>
>
>
> Michael
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Christian Lamprechter
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
>