Version française
Home     About     Download     Resources     Contact us    
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: -- (:)
From: Jacques GARRIGUE <garrigue@k...>
Subject: Re: [Caml-list] Re: GODI
From: Christophe TROESTLER <Christophe.Troestler@umh.ac.be>
> 
> Sven should say better what is possible but my idea is that GODI and
> the Debian package system talk to each other.  So there should NOT be
> two Pervasives modules.  If the GODI (Debian) package is installed,
> the other Ocaml packages should make use of it.  If GODI wants to
> recompile some Debian Package, either (1) delegate the task to the
> Debian package manager (say there is a new version of the package
> available or else use dpkg to download and build from source) or (2)
> consider Debian packages as "on hold" and refuse the GODI operation.
> 
> That requires a correspondance between package names on the two sides
> -- thus some dialog with the Debian maintainers -- but it is a good
> idea not to have different names for a given package anyway...

What you are saying amounts more or less to basing GODI on the debian
packaging system. Interfacing between packaging systems is going to be
just as difficult as interfacing between GC's: almost impossible if
you are not a guru of the two systems. And then why not do it for all
other packaging systems around (rpm, portage, freebsd packages...)

I think that it would be much more reasonable to have a packaging
system controlling all of ocaml, but only ocaml. This includes
compiling and installing from CVS, because those are the cases when a
recompiling package system is really necessary, and because many
developpers (and potential contributors to GODI) are using CVS
versions of ocaml.

The interface to external packaging systems could be just minimal:
external packaging systems handle non-ocaml dependencies, and issue
GODI commands for installing/uninstalling the package. Since GODI may
have to recompile things later, having an external packaging system
trying to track GODI files would be a pain, and probably a useless
one.

This also makes me think that godi should not handle non-ocaml
packages (like gdbm currently), because this is only going to generate
frictions with other packaging systems.

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.

And of course, lots of maintenance needed. I must be using exotic
architectures, but godi never worked properly on any of my machines
(solaris8/x86  and freebsd5.2), at least without lots of tweaking.
Making it work properly on a lot of platforms will require a huge
amount of work, and cannot be handled by a single developper.
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.

By the way I'm ready to help, if there is some understandable way to
do so.

---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>

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