[Omake] Workaround to support OCaml cyclic dependencies?

[Tom Murray]

Thanks, that gave me the (ugly) idea below, which does at least work, to
basically disable the scanner for the modules that have cyclic interface
dependencies. I suppose one way that this could be done more cleanly is to
take the ocamldep output and, for those modules that have an .mli file,
assume that the dependency is on the .cmi only, and not the .cmo/.cmx.

It's interesting, because the philosophy of compilation in something like
Java or Eiffel (Meyer states it rather emphatically at one point) is that
the code should be able to have any structure that is appropriate to the
problem, and the compiler is supposed to sort it out. From what I can tell,
the only fundamental reason that this is precluded in a system like OCaml is
that types and values can be redefined arbitrarily, so that an ordering of
compilation units is required to specify the desired output unambiguously.

I know the OMake team is full of compiler experts--does that sound right or
am I missing another complication?

Cheers,

tm



## Begin OMakefile

FILES[] =
   bar
   foo


LIB = foobar


section:
    .SCANNER: scan-ocaml-foo:
        echo

    %.cmx %$(EXT_OBJ): %.ml %.cmi :scanner: scan-ocaml-foo
        $(OCamlOpt) -c $<
    foo$(EXT_OBJ) foo.cmx: bar.cmi
    bar$(EXT_OBJ) bar.cmx: foo.cmi


.DEFAULT: $(OCamlLibrary $(LIB), $(FILES) foo)

## End OMakefile


On 4/19/07, Aleksey Nogin <nogin at metaprl.org> wrote:
>
> On 18.04.2007 20:22, Tom Murray wrote:
>
> > This type of case arises when, say, Foo uses some types in Bar, but Bar
> > uses some functions in Foo. The easy workaround is to move the shared
> > types to BarTypes, but I noticed that this sort of thing does compile
> > with ocamlc on the command line, but couldn't figure out a way to get
> > OMake to do it.
> >
> > Mostly an academic question, but there are (at least debatable) cases
> > where this type of structure would make sense.
>
> Tom,
>
> The issue is that ocamldep does not distinguish the "dependency on the
> type" from the "dependency on implementation", so OMake has no way of
> knowing. Overriding this for native code would probably mean having to
> mess with scanner rules (tricky), but if you are only interested in byte
> code, you just need to override the OCamlLinkSort function so that OMake
> does not try to order the .cmo files and make sure you give the correct
> ordering manually.
>
> E.g.
>
> NATIVE_ENABLED = false
> BYTE_ENABLED = true
> OCamlLinkSort(nodes) =
>      value $(nodes)
>
> .DEFAULT: $(OCamlProgram xyz, foo bar)
>
> Aleksey
> _______________________________________________
> Omake mailing list
> Omake at metaprl.org
> https://lists.metaprl.org/mailman/listinfo/omake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.metaprl.org/pipermail/omake/attachments/20070419/19d96e1d/attachment-0001.html