12982Re: "ocaml_beginners":: Any experience using oasis?
- Dec 1, 2011-[ Thu, Dec 01, 2011 at 09:09:33AM +0100, Gabriel Scherer ]----
> 1. C compilers are extremely lenient about compile order; basicallyEither I don't see what you are referring to or your statement mix
> 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
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 outsideI don't know what caching mechanism you are referring to, but traditional
> 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.
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/deploymentYes, Makefiles are not for packaging things, and I'm not questioning
> 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.
the use for a good packaging system. I'm only discussing the merit of
the complexity added by custom _build_ systems over makefiles, not
Anyway, GODI is build on top of makefiles so make can be part of the
tool set for a good packaging system too :-)
- << Previous post in topic Next post in topic >>