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 TAA05894; Sun, 2 Mar 2003 19:21:32 +0100 (MET) 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 TAA04975 for ; Sun, 2 Mar 2003 19:21:30 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h22ILQT20573; Sun, 2 Mar 2003 19:21:26 +0100 (MET) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA06108; Sun, 2 Mar 2003 19:21:26 +0100 (MET) Date: Sun, 2 Mar 2003 19:21:26 +0100 From: Xavier Leroy To: Jacques Garrigue Cc: caml-list@inria.fr Subject: Re: [Caml-list] Alternative proposal: COAN Message-ID: <20030302192126.A4892@pauillac.inria.fr> References: <02103BF1-4835-11D7-B97A-000A95773ED2@rouaix.org> <15963.19322.759255.37091@gargle.gargle.HOWL> <20030228182016D.garrigue@kurims.kyoto-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20030228182016D.garrigue@kurims.kyoto-u.ac.jp>; from garrigue@kurims.kyoto-u.ac.jp on Fri, Feb 28, 2003 at 06:20:16PM +0900 X-Spam: no; 0.00; caml-list:01 jacques:01 exploded:99 checksums:01 uninstall:01 ocamlc:01 -where:01 avoided:01 stdlib:01 subdir:01 contrib:01 ocamlfind:01 stringent:99 reasonnable:01 cygwin:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > [Package management in OCaml] I'm catching up on this interesting discussion, and find myself in violent agreement with Jacques: something like the BSD "ports" system, concentrating on (re-)compilation from sources and dependency management, sounds like a strong starting point. I tried to read the BSD "ports" manual once, and my head exploded midway :-) I hope we can simplify things a bit, though. > * For me the central repository should not contain the source themselves. I agree it should be sufficient to give a URL to the sources in the metadata describing the package. In some cases, library authors cannot provide a really stable URL, hence some kind of mirrorring of the sources might be necessary. (And is a real nightmare to do: INRIA can easily provide lots of disk space and bandwith, but making sure that no-one uses the INRIA mirror to trade warez is the hard part :-) But, yes, let's desing the system around the idea that sources are to be downloaded from arbitrary URLs, like BSD ports do. > * Dependency resolution and automatic recompilation/reinstallation is > the core of the problem. Agreed. What do you envision for this? Is it enough for each package to list the names and version number ranges for all the packages it needs? Or shall we try to exploit additionally the dependency information (MD5 checksums of imported modules) already present in compiled OCaml files? > I personally don't think that standardizing the tools to produce > individual package is a useful move. It's not necessary, but could help. For the packaging tools to work, each port will have to contain a makefile or shell script that implements correctly a basic, shared protocol, e.g. "configure, compile, and install yourself", or "uninstall yourself". Providing template makefiles that implement this protocol could help library authors do the packaging. Also, as Nikolaj pointed out, precious few OCaml libraries build on Windows. That's basically because most library authors don't know anything beyond Unix. Again, template makefiles could help overcome this issue. Speaking of this, I've been considering generating a Makefile.inc file as part of the OCaml installation, containing useful information such as "where is the OCaml library?", "what version of OCaml is this?", and "is the native code compiler supported?". By just putting include `ocamlc -where`/Makefile.inc in your makefiles, most of the need for an autoconfiguration script could be avoided. Finally, some standardization on where packages install their files would help the end user. Some packages install one module in the OCaml stdlib dir, others install in a subdir of the stdlib, others install in the "contrib" subdir, etc. OCamlfind can handle all this, but I believe more stringent guidelines on where libraries should go would help. > One last comment on Windows. Since most development is taking place on > Unix, I think this is reasonnable to make the presence of basic cygwin > tools a requirement for compiling packages. The presence of gnu make > and some shell commands should be enough for most. Handling of C > libraries is more complex, but this must often be handled also at the > source level. After years of struggling with nmake, I finally decided to rely on GNU make and the Cygwin tools for building the windows versions of OCaml. So, I agree that assuming Cygwin is present for building packages is a reasonable thing to do. Still, writing a makefile that works both under Unix and Windows isn't trivial, due to stupid things like different file extensions for C libraries (.a vs. .lib). At least, I haven't yet succeeded in having common makefiles for Unix and Windows in the OCaml source tree. - Xavier Leroy ------------------- 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