From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kevin Ryde Newsgroups: gmane.lisp.guile.user Subject: Re: Managing Guile and extensions versions Date: Sun, 02 Oct 2005 11:59:47 +1000 Message-ID: <87d5mou19o.fsf@zip.com.au> References: <6efab235050925145055ba774c@mail.gmail.com> <873bns2f26.fsf@laas.fr> <6efab2350509261220665afe20@mail.gmail.com> <87br2ezyth.fsf@laas.fr> <6efab235050927035441b39b85@mail.gmail.com> <874q86qzuk.fsf@laas.fr> <6efab235050927101826b2da7d@mail.gmail.com> <87d5mtis5l.fsf_-_@laas.fr> <87y85fpl60.fsf@zip.com.au> <87ll1frnni.fsf@laas.fr> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1128218547 30178 80.91.229.2 (2 Oct 2005 02:02:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 2 Oct 2005 02:02:27 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Oct 02 04:02:23 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ELtAp-00046B-3t for guile-user@m.gmane.org; Sun, 02 Oct 2005 04:01:55 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ELtAo-0003Z3-F4 for guile-user@m.gmane.org; Sat, 01 Oct 2005 22:01:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ELtAc-0003XI-Of for guile-user@gnu.org; Sat, 01 Oct 2005 22:01:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ELtAZ-0003Vw-VE for guile-user@gnu.org; Sat, 01 Oct 2005 22:01:40 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ELtAZ-0003VN-Ol for guile-user@gnu.org; Sat, 01 Oct 2005 22:01:39 -0400 Original-Received: from [61.8.0.84] (helo=mailout1.pacific.net.au) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ELt8y-0004mi-Js for guile-user@gnu.org; Sat, 01 Oct 2005 22:00:01 -0400 Original-Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j921xrrl009804 for ; Sun, 2 Oct 2005 11:59:53 +1000 Original-Received: from localhost (ppp2880.dyn.pacific.net.au [61.8.40.128]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j921xpCL016823 for ; Sun, 2 Oct 2005 11:59:52 +1000 Original-Received: from gg by localhost with local (Exim 3.36 #1 (Debian)) id 1ELt8l-0000xF-00; Sun, 02 Oct 2005 11:59:47 +1000 Original-To: guile-user@gnu.org User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:4804 Archived-At: ludovic.courtes@laas.fr (Ludovic Court=E8s) writes: > > In fact, Libtool's versioning mechanism already makes this possible for > programs: the loader and/or dynamic linker chooses the one version of > the library the program expects to be linked against. Oh, well, libtool only wraps what ld.so does, but yes. > For instance, `dlopen ("/lib/mylib.so.2.3.4")' does > load a specific version of the lib, but in a non-portable and unclear > way. `libltdl' could provide a higher-level, portable API to do such > things. I think difficulties with two .la's at the same time has been a more-or-less known issue for quite a while. There may be plans afoot, but you might have observed the pace of libtool development is, well, glacial. (No disrespect to the libtool developers, it's a big and arcane beast.) > (However, I'd be glad to hear your thoughts about adding support for > versioning to Guile's module system.) I believe it needs very careful thought, because it's about planning for or imagining what the future will look like, something that's far from settled. A system of versions virtually concedes that compatibility won't be maintained, and that some kind of perpetual revision or at least rebuilding of modules will be necessary. It'd be better if that could be avoided. I think the present seems worse than it is, because the last couple of releases have had a lot of changes. If it settles down then the need to version stuff like crazy ought to vanish. The doco for the present is pretty light-on though. Perhaps only power-users have gone beyond the basics. :-) I'm not aware of any outright show-stoppers in the code though, not for any sensible sort of arrangement. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user