English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] Dynamically evaluating OCaml code
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-04-14 (06:53)
From: Jacques GARRIGUE <garrigue@k...>
Subject: Re: [Caml-list] Re: GODI vs. Ocamake
From: "Brandon J. Van Every" <vanevery@indiegamedesign.com>
> Jacques GARRIGUE wrote:
> >
> > I think that it would be much more reasonable to have a packaging
> > system controlling all of ocaml, but only ocaml.
> Reasonable, but foreign libraries aren't going away.  Not until OCaml
> has everything under its own roof, and that will be quite some time.  A
> proper OCaml package system will have deal with foreign libraries
> somehow, even if the support is half-assed.

What I meant was just that the packaging system should not try to
replace the native package system of the platform for non-ocaml
stuff. But it must of course handle stub libraries, and even
dependencies on external libraries. GODI makes some nice attempt at
that, through configuration pseudo-packages, that let it know how some
external libraries should be used.

> > Last, we need support for windows, and for binary packages.
> I hope you only mean "last" as a way of listing things needed, i.e.

This just happened to be the end of my mail, when I was writing it,
but then I added more stuff, and last was invalidated.
By the way, the full paragraph was clear enough:

  Last, we need support for windows, and for binary packages. I don't
  know who is going to do it, but these are requirements to make godi
  the standard.

> So how is OCamake?  Is it not the obvious place to begin?

OCamake is a useful tool, but its goal is simplifying the building of
individual programs or libraries. It has no support for packaging or
recompilation that I know of. I believe the two problems are

Jacques Garrigue

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