Loading ...
Sorry, an error occurred while loading the content.

12982Re: "ocaml_beginners"::[] Any experience using oasis?

Expand Messages
  • rixed@happyleptic.org
    Dec 1, 2011
      -[ Thu, Dec 01, 2011 at 09:09:33AM +0100, Gabriel Scherer ]----
      > 1. C compilers are extremely lenient about compile order; basically
      > you can give *.c files in any order you like, there is no cross-file
      > dependency (but a common inclusion of .h files in the source) before
      > linking; on the contrary OCaml is quite strict to get file paths in
      > correct dependency order. Some build systems are impractical if you
      > need strict file ordering, as they assume order doesn't matter so
      > much.

      Either I don't see what you are referring to or your statement mix
      compilation with linking.

      AFAIK OCaml independent compilation mechanisms is copied from C, ie. you
      can compile any file independently of the others, in any order. I never
      encountered any difference between OCaml and C in this regard. So
      compilation is as easily handled by make in OCaml than in C (with the
      same drawback as in C: make is relying only on the file timestamp so
      changing a mere comment can yield a great amount of useless

      Linking is another matter, since the unix system linker is not
      independent of the order of files on its command line. This is, again,
      the same with OCaml (although the order is reversed: while the
      traditional Unix linker will include symbols from a file if they were
      referenced in previous files, the OCaml linker requires that all
      mentioned modules in a file been already linked).

      All in all, I'm under the impression that OCaml build was inspired
      from C, perhaps because they regarded it as quite good (indeed, the make
      tool awarded an ACM prize to it's creator according to wikipedia :-)).
      This is one of OCaml aspect that makes this language attractive to C
      folks, I guess.

      > 2. C files quite rarely need to be recompiled, as they deduce outside
      > interfaces from their .h rather than depending on other modules, and
      > have a quite lenient compatibility story; on the contrary, OCaml has
      > an overly strict technique to guarantee type safety and representation
      > coherence, it computes hashes of whole compilation units and require
      > all files depending on them to be recompiled if their change
      > Makefile caching mechanism will typically not be aware of point (2),
      > which explains the not-infrequent "foo.cmi and bla.cmi makes
      > inconsistent assumptions" error message.

      I don't know what caching mechanism you are referring to, but traditional
      make does not cache anything. The only occurrences of the not-infrequent
      error message about mismatch in module hashes I ever stumble upon
      involves cross-project builds (ie files A and B of project X uses
      external library Y, A and B are compiled alright then I recompile Y
      then go back to X and make a change in either A or B but not both ->
      boom!). I would says this relates to how dependencies are tracked, which
      is not make's business.

      > You have the same problem on the packaging/deployment
      > front: usual Unix packaging systems do not expect to have to upgrade,
      > say, the 'lwt' package whenever the 'ocaml' package gets an upgrade.
      > GODI and, for example, the Debian ocaml packaging team, use special
      > techniques to force recompilation / binary upgrade.

      Yes, Makefiles are not for packaging things, and I'm not questioning
      the use for a good packaging system. I'm only discussing the merit of
      the complexity added by custom _build_ systems over makefiles, not
      packaging systems.
      Anyway, GODI is build on top of makefiles so make can be part of the
      tool set for a good packaging system too :-)
    • Show all 13 messages in this topic