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 NAA14363; Mon, 11 Mar 2002 13:15:37 +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 NAA15363 for ; Mon, 11 Mar 2002 13:15:37 +0100 (MET) Received: from pD951B059.dip.t-dialin.net (pD951B059.dip.t-dialin.net [217.81.176.89]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g2BCFZ106607 for ; Mon, 11 Mar 2002 13:15:35 +0100 (MET) Received: from hera.ffm.npc.de (hera.ffm.npc.de [192.168.130.8]) by pD951B059.dip.t-dialin.net (Postfix STYX NPC GmbH) with ESMTP id E715F78E0 for ; Mon, 11 Mar 2002 13:15:30 +0100 (CET) Received: from gerd-stolpmann.de (ares.ffm.npc.de [192.168.130.32]) by hera.ffm.npc.de (Postfix HERA NPC GmbH) with ESMTP id E83A456F3 for ; Mon, 11 Mar 2002 13:15:29 +0100 (CET) Message-ID: <3C8C9FE1.2060904@gerd-stolpmann.de> Date: Mon, 11 Mar 2002 13:15:29 +0100 From: Gerd Stolpmann User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: caml-list@inria.fr Subject: Re: [Caml-list] The DLL-hell of O'Caml References: <026e01c1c8b5$32f11260$de5b6620@mdaxke> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Mark D. Anderson wrote: > If someone is going to work on this, I'd recommend they look even more deeply > at what perl and python do. It is more than just "download over http"; there > are also issues of versioning among others. But there is a fundamental difference: These language don't have strict typing, and they bind identifiers always dynamically. It is no problem to replace a version of a library by a newer one. Of course, this can also break functionality, but it is possible to develop module interfaces conservatively. In O'Caml replacing library X by a newer version usually means that all libraries Y that depend on X must be recompiled. And there is no guarantee that Y can be compiled at all. I do not see any chance to change this, it is a consequence of strict typing. So an automatic installer for O'Caml needs: - A local source repository that stores all sources so modules can be recompiled if necessary - Knowledge about the versions of modules, especially which versions of dependent modules work together and which don't > Some of the things both those languages have, to greater or lesser degrees: > > - there is a web site for humans with search and list, such as search.cpan.org We have already two, but they are for humans only. > - there is a command line which does search, list, and install, such as > "perl -MCPAN -e shell" or "ppm" > (ppm is more an activestate thing; CPAN.pm is distributed) > The install can deal with recursive dependencies if you want. If it is only search/list/install package management is quite easy. We need a file format that contains the instructions how to build a package from source. But upgrades are more complicated, as explained. > - the install utility can handle pure language packages, mixed language packages > with C source, and mixed language packages with pre-compiled C source > for one architecture (ppm is less flexible but simpler). > > - really obscene things can be done with the perl "Inline" module: http://search.cpan.org/search?dist=Inline > > - a single language install tree can handle a mixture of binary modules that vary by > architecture (i686-linux vs. MSWin32-x86-multi-thread) or by language version (5.005 vs. 5.6). > pure-language modules can vary by language version. > This is useful for multiple developers sharing a single install over NFS, or for > a single developer that is trying out multiple configurations. Again, this works only because the modules are loosely coupled. > - the language runtime does best effort when a package is asked for by name, > taking the "best-fit" one; > this prevents you having to upgrade all packages just because the language is > upgraded. Maybe we are on the wrong track if we want to mimick Perl's installer. Maybe it is better not to have a fully automatic system but a system that is more user-friendly. I can imagine a graphic tool would be helpful that visualizes the current state of the installation, that explains possible operations, and that assists the user when carrying them out. For example, if a package is upgraded, this tool would not try to recompile the dependent packages automatically, but it would display that these packages are currently invalid and need to be replaced. The user would have the chance to control the next steps. One possibility would be to try to recompile the old version again, another would be to get a new version from a remote repository. The point is that it is under the control of the user, and that the graphic visualization allows even beginners to manage upgrades. Gerd ------------------- 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