Re: [Caml-list] Alternative proposal: COAN

[Xavier Leroy <xavier.leroy@inria.fr>]

> [Package management in OCaml]

I'm catching up on this interesting discussion, and find myself in
violent agreement with Jacques: something like the BSD "ports" system,
concentrating on (re-)compilation from sources and dependency
management, sounds like a strong starting point.  

I tried to read the BSD "ports" manual once, and my head exploded
midway :-)  I hope we can simplify things a bit, though.

> * For me the central repository should not contain the source themselves.

I agree it should be sufficient to give a URL to the sources in the
metadata describing the package.  In some cases, library authors
cannot provide a really stable URL, hence some kind of mirrorring of
the sources might be necessary.  (And is a real nightmare to do: INRIA
can easily provide lots of disk space and bandwith, but making sure
that no-one uses the INRIA mirror to trade warez is the hard part :-)
But, yes, let's desing the system around the idea that sources are to
be downloaded from arbitrary URLs, like BSD ports do.

> * Dependency resolution and automatic recompilation/reinstallation is
>   the core of the problem.

Agreed.  What do you envision for this?  Is it enough for each package
to list the names and version number ranges for all the packages it
needs?  Or shall we try to exploit additionally the dependency
information (MD5 checksums of imported modules) already present in
compiled OCaml files?  

> I personally don't think that standardizing the tools to produce
> individual package is a useful move.

It's not necessary, but could help.  For the packaging tools to work,
each port will have to contain a makefile or shell script that
implements correctly a basic, shared protocol, e.g. "configure,
compile, and install yourself", or "uninstall yourself".  Providing
template makefiles that implement this protocol could help library
authors do the packaging.  

Also, as Nikolaj pointed out, precious few OCaml libraries build on
Windows.  That's basically because most library authors don't know
anything beyond Unix.  Again, template makefiles could help overcome
this issue.

Speaking of this, I've been considering generating a Makefile.inc file
as part of the OCaml installation, containing useful information such
as "where is the OCaml library?", "what version of OCaml is this?",
and "is the native code compiler supported?".  By just putting
        include `ocamlc -where`/Makefile.inc
in your makefiles, most of the need for an autoconfiguration script
could be avoided.

Finally, some standardization on where packages install their files
would help the end user.  Some packages install one module in the
OCaml stdlib dir, others install in a subdir of the stdlib, others
install in the "contrib" subdir, etc.  OCamlfind can handle all this,
but I believe more stringent guidelines on where libraries should go
would help.

> One last comment on Windows. Since most development is taking place on
> Unix, I think this is reasonnable to make the presence of basic cygwin
> tools a requirement for compiling packages. The presence of gnu make
> and some shell commands should be enough for most. Handling of C
> libraries is more complex, but this must often be handled also at the
> source level.

After years of struggling with nmake, I finally decided to rely on GNU
make and the Cygwin tools for building the windows versions of OCaml.
So, I agree that assuming Cygwin is present for building packages is a
reasonable thing to do.  Still, writing a makefile that works both
under Unix and Windows isn't trivial, due to stupid things like
different file extensions for C libraries (.a vs. .lib).  At least, I
haven't yet succeeded in having common makefiles for Unix and Windows
in the OCaml source tree.

- Xavier Leroy

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