[Caml-list] ocambuild vs ocamldep circular dependencies

[Caml-list] ocambuild vs ocamldep circular dependencies

[Soegtrop, Michael]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4886 bytes --]

Re: [Caml-list] ocambuild vs ocamldep circular dependencies

[Gabriel Scherer]

[-- Attachment #1: Type: text/plain, Size: 5229 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 7312 bytes --]

RE: [Caml-list] ocambuild vs ocamldep circular dependencies

[Soegtrop, Michael]

[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]

Dear Gabriel,

The current implementation happens to allow them, but this does not mean that they are "valid programs".
I see what you mean: since I can’t put both modules into a single file without changing the two let into let rec / and or using recursive modules, it is not valid OCaml, although the compiler accepts it if presented separately.

Let me see what I can do here. The mutual dependent part is a large part of both modules so it wouldn’t be very nice to put them into one file. But if it is the only option to get a valid OCaml program, I will look into it.

Still I think it is unfortunate that OCaml doesn’t support this. It makes it harder to structure software in an aspect oriented way. For simple data structures it is fine to bundle all aspects into a single module or file. For a data structure like a C AST, the module / file will get quite large. I can separate off the statements easily, but this is only a small part of the AST. The largest part are expressions and types, and these are recursively dependent on each other.

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

[-- Attachment #2: Type: text/html, Size: 4850 bytes --]

Re: [Caml-list] ocambuild vs ocamldep circular dependencies

[Petter A. Urkedal]

There is a way to do it if I understood the problem right by
functorizing and linking explicitly with the `module rec` construct:

$ cat first_sig.mli
module type S = sig
  type a
  type b
  val null : unit -> a
  val succ : b -> a
end

$ cat second_sig.mli
module type S = sig
  type a
  type b
  val null : b
  val succ : a -> b
end

$ cat first.ml
module Make (X : Second_sig.S) = struct
  type b = X.b
  type a = N | B of b
  let null () = N
  let succ x = B x
end

$ cat second.ml
module Make (X : First_sig.S) = struct
  type a = X.a
  type b = N | A of a
  let null = N
  let succ x = A x
end

$ cat both.ml
module rec A : First_sig.S with type b = B.b = First.Make (B)
       and B : Second_sig.S with type a = A.a = Second.Make (A)

There are typically some shared types at the top of the signatures,
which could be put into a separate file and included.


On 9 July 2016 at 17:16, Soegtrop, Michael <michael.soegtrop@intel.com> wrote:
> Dear Gabriel,
>
>
>
> The current implementation happens to allow them, but this does not mean
> that they are "valid programs".
>
> I see what you mean: since I can’t put both modules into a single file
> without changing the two let into let rec / and or using recursive modules,
> it is not valid OCaml, although the compiler accepts it if presented
> separately.
>
>
>
> Let me see what I can do here. The mutual dependent part is a large part of
> both modules so it wouldn’t be very nice to put them into one file. But if
> it is the only option to get a valid OCaml program, I will look into it.
>
>
>
> Still I think it is unfortunate that OCaml doesn’t support this. It makes it
> harder to structure software in an aspect oriented way. For simple data
> structures it is fine to bundle all aspects into a single module or file.
> For a data structure like a C AST, the module / file will get quite large. I
> can separate off the statements easily, but this is only a small part of the
> AST. The largest part are expressions and types, and these are recursively
> dependent on each other.
>
>
>
> 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

Re: [Caml-list] ocambuild vs ocamldep circular dependencies

[Jonathan Protzenko]

FYI, here's how the source code of OCaml deals with this very problem.

https://github.com/ocaml/ocaml/blob/trunk/typing/typecore.ml#L84 
(forward reference...)

https://github.com/ocaml/ocaml/blob/trunk/typing/typemod.ml#L1564 
(filled later on).

Arguably a dirty hack, but works really nicely in practice imho. Works 
with OCamlbuild too.

~ jonathan

On 7/9/16 9:16 AM, Petter A. Urkedal wrote:
> There is a way to do it if I understood the problem right by
> functorizing and linking explicitly with the `module rec` construct:
>
> $ cat first_sig.mli
> module type S = sig
>    type a
>    type b
>    val null : unit -> a
>    val succ : b -> a
> end
>
> $ cat second_sig.mli
> module type S = sig
>    type a
>    type b
>    val null : b
>    val succ : a -> b
> end
>
> $ cat first.ml
> module Make (X : Second_sig.S) = struct
>    type b = X.b
>    type a = N | B of b
>    let null () = N
>    let succ x = B x
> end
>
> $ cat second.ml
> module Make (X : First_sig.S) = struct
>    type a = X.a
>    type b = N | A of a
>    let null = N
>    let succ x = A x
> end
>
> $ cat both.ml
> module rec A : First_sig.S with type b = B.b = First.Make (B)
>         and B : Second_sig.S with type a = A.a = Second.Make (A)
>
> There are typically some shared types at the top of the signatures,
> which could be put into a separate file and included.
>
>
> On 9 July 2016 at 17:16, Soegtrop, Michael <michael.soegtrop@intel.com> wrote:
>> Dear Gabriel,
>>
>>
>>
>> The current implementation happens to allow them, but this does not mean
>> that they are "valid programs".
>>
>> I see what you mean: since I can’t put both modules into a single file
>> without changing the two let into let rec / and or using recursive modules,
>> it is not valid OCaml, although the compiler accepts it if presented
>> separately.
>>
>>
>>
>> Let me see what I can do here. The mutual dependent part is a large part of
>> both modules so it wouldn’t be very nice to put them into one file. But if
>> it is the only option to get a valid OCaml program, I will look into it.
>>
>>
>>
>> Still I think it is unfortunate that OCaml doesn’t support this. It makes it
>> harder to structure software in an aspect oriented way. For simple data
>> structures it is fine to bundle all aspects into a single module or file.
>> For a data structure like a C AST, the module / file will get quite large. I
>> can separate off the statements easily, but this is only a small part of the
>> AST. The largest part are expressions and types, and these are recursively
>> dependent on each other.
>>
>>
>>
>> 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

RE: [Caml-list] ocambuild vs ocamldep circular dependencies

[Soegtrop, Michael]

Dear Petter, Jonathan,

thanks for the hints! I think the function reference method is indeed a hack (it is also mentioned on http://wiki.xenproject.org/wiki/OCaml_Cyclical_Build_Dependencies ). The rec module approach is cleaner, but usually quite a bit of work. In the end I decided to rearrange my code so that the functions in question end up in one module. The effort is similar to the effort of implementing the module rec approach.

I still think that this is a substantial drawback of OCaml. It can be hard to foresee if one will stumble across this in larger projects, and it is not so nice that design decisions on the structure of modules are forced by this.

Couldn't one think of a way of declaring the existence of a module, with just its signature given? With such a mechanism, one could treat a reference to a module as a reference to the signature in the .mli file rather than to its implementation.

Best regards,

Michael

> -----Original Message-----
> From: Jonathan Protzenko [mailto:jonathan.protzenko@gmail.com]
> Sent: Saturday, July 09, 2016 10:10 PM
> To: Petter A. Urkedal
> Cc: Gabriel Scherer; caml-list@inria.fr; Soegtrop, Michael
> Subject: Re: [Caml-list] ocambuild vs ocamldep circular dependencies
> 
> FYI, here's how the source code of OCaml deals with this very problem.
> 
> https://github.com/ocaml/ocaml/blob/trunk/typing/typecore.ml#L84
> (forward reference...)
> 
> https://github.com/ocaml/ocaml/blob/trunk/typing/typemod.ml#L1564
> (filled later on).
> 
> Arguably a dirty hack, but works really nicely in practice imho. Works with
> OCamlbuild too.
> 
> ~ jonathan
> 
> On 7/9/16 9:16 AM, Petter A. Urkedal wrote:
> > There is a way to do it if I understood the problem right by
> > functorizing and linking explicitly with the `module rec` construct:
> >
> > $ cat first_sig.mli
> > module type S = sig
> >    type a
> >    type b
> >    val null : unit -> a
> >    val succ : b -> a
> > end
> >
> > $ cat second_sig.mli
> > module type S = sig
> >    type a
> >    type b
> >    val null : b
> >    val succ : a -> b
> > end
> >
> > $ cat first.ml
> > module Make (X : Second_sig.S) = struct
> >    type b = X.b
> >    type a = N | B of b
> >    let null () = N
> >    let succ x = B x
> > end
> >
> > $ cat second.ml
> > module Make (X : First_sig.S) = struct
> >    type a = X.a
> >    type b = N | A of a
> >    let null = N
> >    let succ x = A x
> > end
> >
> > $ cat both.ml
> > module rec A : First_sig.S with type b = B.b = First.Make (B)
> >         and B : Second_sig.S with type a = A.a = Second.Make (A)
> >
> > There are typically some shared types at the top of the signatures,
> > which could be put into a separate file and included.
> >
> >
> > On 9 July 2016 at 17:16, Soegtrop, Michael <michael.soegtrop@intel.com>
> wrote:
> >> Dear Gabriel,
> >>
> >>
> >>
> >> The current implementation happens to allow them, but this does not
> >> mean that they are "valid programs".
> >>
> >> I see what you mean: since I can’t put both modules into a single
> >> file without changing the two let into let rec / and or using
> >> recursive modules, it is not valid OCaml, although the compiler
> >> accepts it if presented separately.
> >>
> >>
> >>
> >> Let me see what I can do here. The mutual dependent part is a large
> >> part of both modules so it wouldn’t be very nice to put them into one
> >> file. But if it is the only option to get a valid OCaml program, I will look into
> it.
> >>
> >>
> >>
> >> Still I think it is unfortunate that OCaml doesn’t support this. It
> >> makes it harder to structure software in an aspect oriented way. For
> >> simple data structures it is fine to bundle all aspects into a single module
> or file.
> >> For a data structure like a C AST, the module / file will get quite
> >> large. I can separate off the statements easily, but this is only a
> >> small part of the AST. The largest part are expressions and types,
> >> and these are recursively dependent on each other.
> >>
> >>
> >>
> >> 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

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

RE: [Caml-list] ocambuild vs ocamldep circular dependencies

[Soegtrop, Michael]

Dear OCaml Users,

a note for those reading this thread later:

I finally used the module rec approach as outlined by Petter A. Urkedal in his previous post, although some people said in various places that this is overkill if you have issues with just a few functions. The module structure implied by the module rec approach was in the end nicer than my original module structure (which didn't work cause of the circular dependency). It was also much less work to restructure the modules than I thought. I tried several other approaches (function references, putting all functions calling each other into one file, treat mli and ml files separately in the build system), but they all appeared to be inferior, either in terms of effort or in terms of clarity, usually both.

So I came to the conclusion that long term there is no issue with properly declaring recursive module structures using "module rec", although it can be quite a pain short term. For resolving some short term hacks (e.g. for experiments), one can still use the function reference approach.

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

Re: [Caml-list] ocambuild vs ocamldep circular dependencies

[Fabrice Le Fessant]

[-- Attachment #1: Type: text/plain, Size: 2332 bytes --]

FWIW, `ocp-build` has a specific variable to overcome `ocamldep`
limitations.

You can for example describe a library like that:

```
begin library "foobar"
  requires = [ "unix" "my-other-lib" ]
  files = [
       "bar.ml" (nodeps = [ "Foo" ])    (*   <---- module Bar does not
depend on Foo, even if `ocamldep` says the contrary *)
       "foo.ml"
   ]
end
```

It also has a specific algorithm to discover cycles in build rules and
display the cycle in a user-friendly fashion, so that finding the arguments
for `nodeps` becomes easier.

--Fabrice



On Mon, Jul 11, 2016 at 5:33 PM Soegtrop, Michael <
michael.soegtrop@intel.com> wrote:

> Dear OCaml Users,
>
> a note for those reading this thread later:
>
> I finally used the module rec approach as outlined by Petter A. Urkedal in
> his previous post, although some people said in various places that this is
> overkill if you have issues with just a few functions. The module structure
> implied by the module rec approach was in the end nicer than my original
> module structure (which didn't work cause of the circular dependency). It
> was also much less work to restructure the modules than I thought. I tried
> several other approaches (function references, putting all functions
> calling each other into one file, treat mli and ml files separately in the
> build system), but they all appeared to be inferior, either in terms of
> effort or in terms of clarity, usually both.
>
> So I came to the conclusion that long term there is no issue with properly
> declaring recursive module structures using "module rec", although it can
> be quite a pain short term. For resolving some short term hacks (e.g. for
> experiments), one can still use the function reference approach.
>
> 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
>
> --
> 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

[-- Attachment #2: Type: text/html, Size: 3401 bytes --]

Re: [Caml-list] ocambuild vs ocamldep circular dependencies

[Goswin von Brederlow]

On Sat, Jul 09, 2016 at 09:45:46AM -0400, Gabriel Scherer wrote:
> 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".

I thought that only worked with hacks, turning of cross module
inlining to make it build at all.

> 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.

I don't think you have explored all the ways around the circular depends yet.

1) factor out the common parts into a 3rd module used by both
2) use recursive modules
3) lift the recursion (old style): pass a record of callbacks to one
   of the modules to replace the cyclic calls
4) lift the recursion (first class modules): pass one of the modules
   as argument to the other and open it locally

> > 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
> >

MfG
	Goswin