Re: [Caml-list] Re: GODI vs. Ocamake

["Nicolas Cannasse" <warplayer@free.fr>]

> > Which creates another problem: GODI is based on C tools and BSD
> > makefiles. I'm not sure this is the favorite kind of things ocaml
> > programmers would maintain.
>
> An OCaml-centric packaging tool should be written in OCaml.  Nobody's
> switching to OCaml out of their love for C and C++!  If that means GODI
> is unsuitable to task, that is unfortunate but reality is reality.
> Other languages such as Python and Java have spawned their own build
> tools.  There's a lot more to the world than Make.
>
> So how is OCamake?  Is it not the obvious place to begin?

As Jacques Garrigue answered, OCamake have been designed as a compilation
tool, and is actually well suited for the Windows world since it doesn't
rely on any 3rd party tools (apart from ocaml official distribution ones :
ocamlc, ocamlopt and ocamldep) - it still work very well on Unixes. OCamake
does not handle right now the building of C stubs, so it's only building
pure-ocaml projects. But when we jump into the C side, you need a lot of
extra configuration :
    - on windows things here are quite easy, but if you want to support MSVC
+ Mingw ( cygwin being optional IMHO ) it will takes time
    - unix world is very different from windows one, and is already filled
with autoconf like tools that are checking a bunch of things in order to be
able to compile

The idea to enable OCamake to be highly configurable would be to have an
"Ocamake Library" and then you'll write a file "makefile.ml" using that
library in order to ease compilation and ensure you're writing a
system-idependant makefile. Then you'll run ocamake (the tool) that will
dynamicly load the makefile.ml in order to execute it.

This - the system-idenpendant build of C stubs - will require quite a lot of
work on Ocamake, and will require the library owners to write their
makefile.ml compilation files. But in the end we would get a
system-idependant build tool, that can later be used by a package manager in
order to (re)compile a given package (the inter-package dependencies being
handled at the package-manager level). Sadly, a lot of OCaml users are
unixes ones that doesn't care at all about support of systems such as
Windows or MacOs ( and they're sometimes true : when you're writing bindings
to a unix-only library, who cares about your bindings being compilable on
win32 ? ). Theses users are currently happy enough using autoconf / make
since it doesn't require additionnal learning. GODI+findlib are made with
the same thinking : they have not been designed to be SI since they're
basicly (very) smart scripts relying on a lot of other unix tools.

Other way of thinking is : what do we need in order to get binary-only
distributions ? OCaml have a bytecode interpreter, so why we can't release
libraries simply as a big CMA ( and some CMI's ). Answer : because the
bytecode binary format is very strict, and not suited for this kind of usage
(adding a function in the interface of a sub library needs to recompile all
top librairies ). Maybe a more flexible bytecode format would help the
community to build a good packaging tool without having to care about all
theses compilation issues. (of course people would still need to compile for
native code, but there is also here other ways such as providing a
marchalled typed-AST as a binary "reading for input to ocamlopt").

Regards,
Nicolas Cannasse
www.motion-twin.com

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners