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: | skaller <skaller@u...> |
| Subject: | Re: [Caml-list] Re: GODI vs. Ocamake |
On Wed, 2004-04-14 at 17:50, Nicolas Cannasse wrote: > 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. Yes. I agree with this model. The first order of the day is to throw out make and replace it with a general purpose language + a library which make writing program building programs easier. To put this another way, I regard 'autoconf' as one of the worst evils around. The correct solution is a combination of Standards and a full scale programming language -- not hacked up special purpose tools which are so grossly inadequate they need yet *another* tool to configure them .. and still don't work right. For this reason the Felix build processes uses a high power general purpose language, namely Python. The package manager is a high power general purpose programming language, namely Python. The two processes are one and the same and integrated with a library of support functions and some lightweight architecture, namely Interscript, my literate programming, build, and package management tool .. also written entirely in Python. So in theory, it can build and install anything on any operating system, provided only that Python and a reasonable subset of the standard distribution's libraries is installed. Had I commenced the interscript project more recently, I might have chosen the bytecode interpreter of Ocaml instead of Python. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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