From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA02545; Sat, 2 Aug 2003 11:51:53 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA04244 for ; Sat, 2 Aug 2003 11:51:52 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h729pof04927 for ; Sat, 2 Aug 2003 11:51:51 +0200 (MET DST) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3p2/3.7W) with ESMTP id SAA12593; Sat, 2 Aug 2003 18:51:46 +0900 (JST) To: info@gerd-stolpmann.de Cc: caml-list@inria.fr Subject: Re: [Caml-list] GODI available for download In-Reply-To: <20030802122802N.garrigue@kurims.kyoto-u.ac.jp> References: <1059601286.9556.8.camel@ice.gerd-stolpmann.de> <20030802122802N.garrigue@kurims.kyoto-u.ac.jp> X-Mailer: Mew version 1.94.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20030802185229D.garrigue@kurims.kyoto-u.ac.jp> Date: Sat, 02 Aug 2003 18:52:29 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) X-Loop: caml-list@inria.fr X-Spam: no; 0.00; jacques:01 caml-list:01 camlimages:01 lablgl:01 lablgtk:01 mismatch:01 cpan:01 ocamake:01 gmake:01 ocaml:01 garrigue:01 handles:01 behaviour:01 makefile:02 commands:97 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Some more considerations on my experience. > Next, building godi-ocaml and godi-ocaml-labltk. godi-ocaml went fine, > but godi-ocaml-labltk failed, because it needs some configuration > options (I see no way to pass them). Since I'm used to BSD packages, I > go to the godi-ocaml-labltk/work directory, and reconfigure by hand. I realize now that this configuration problem is going to be very complicated. BSD packages are OS-oriented: they assume a closed world, where everything is controlled by the packaging system. So you don't need to tell them where something is on the system, they already know it. With godi, the situation is different. For instance, tcl/tk headers may be in many places, maybe even several versions of them, and the user should be able to indicate where to find them. Same thing for camlimages, lablgl, lablgtk, etc... My feeling is that there has to be a way to give this information by hand the first time you install a package, and these parameters would be reused in following installations. When the package is installed as a dependency, this may require some interaction from the user. Also, the possibility of finishing the work by hand must be left, otherwise recovering from simple configurations bugs can become unwieldly. I'm afraid this is just one example of mismatch between an OS-oriented packager and a language-oriented multi-platform packager. Another one is the use of makefiles internally and in packages. While makefiles are not intrinsically bad, they have one big default: they depend heavily on the behaviour of external commands on the system. If you have only platform this is not a problem: you just have to check once that this works, but if you must handle multiple platforms, it is very hard to be sure that the Makefile is portable. I don't know how CPAN handles that, but this is going to be painful. Using an ocaml only tool like ocamake may be an interesting option, at least for simple packages. Just some thoughts. I certainly believe that godi is a big step in the right direction. Jacques Garrigue P.S. A small detail, but would it be hard to replace godi_ftp by fetch? On my system godi_ftp is 351K whereas fetch is only 18K. I suppose this is also reflected by the size of the sources. I wonder also if there is a packaging system based on gmake rather than bmake. It feels a bit strange to install bmake only for internal purposes. ------------------- 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