Browse thread
[Caml-list] Dynamically evaluating OCaml code
-
John Goerzen
- Vitaly Lugovsky
- Samuel Mimram
-
Basile Starynkevitch
-
Issac Trotts
- Dustin Sallings
-
Brian Hurt
- Oleg Trott
- Ville-Pertti Keinonen
-
John Goerzen
-
Markus Mottl
-
Richard Jones
-
Markus Mottl
- Jon Harrop
-
John Goerzen
- Jean-Marc EBER
-
Trevor Andrade
-
Gerd Stolpmann
- skaller
-
John Goerzen
-
Gerd Stolpmann
-
Christophe TROESTLER
-
Gerd Stolpmann
-
Christophe TROESTLER
- Brandon J. Van Every
- John Goerzen
- Jacques GARRIGUE
-
Christophe TROESTLER
-
Gerd Stolpmann
-
Christophe TROESTLER
- Matt Gushee
-
Gerd Stolpmann
- Benjamin Geer
-
Gerd Stolpmann
- skaller
-
Markus Mottl
- John Goerzen
- Jon Harrop
-
Richard Jones
- Fernando Alegre
- Jean-Marc EBER
- Kenneth Knowles
- Brian Hurt
- skaller
-
Markus Mottl
- Issac Trotts
- Basile Starynkevitch
-
Issac Trotts
- clement capel
- Jon Harrop
- Walid Taha
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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