From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludovic.courtes@laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.user Subject: Re: Managing Guile and extensions versions Date: Thu, 29 Sep 2005 17:34:37 +0200 Organization: LAAS-CNRS Message-ID: <871x3728he.fsf@laas.fr> 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> <6efab235050928131950e30e8c@mail.gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1128008908 9592 80.91.229.2 (29 Sep 2005 15:48:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 29 Sep 2005 15:48:28 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Sep 29 17:48:14 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EL0cp-0008Hl-9Y for guile-user@m.gmane.org; Thu, 29 Sep 2005 17:47:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EL0co-0002z4-Ns for guile-user@m.gmane.org; Thu, 29 Sep 2005 11:47:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EL0bX-00026m-UK for guile-user@gnu.org; Thu, 29 Sep 2005 11:45:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EL0bT-00023K-8f for guile-user@gnu.org; Thu, 29 Sep 2005 11:45:48 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EL0bS-0001tK-B6 for guile-user@gnu.org; Thu, 29 Sep 2005 11:45:46 -0400 Original-Received: from [140.93.0.15] (helo=laas.laas.fr) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EL0XP-0003Fm-8X for guile-user@gnu.org; Thu, 29 Sep 2005 11:41:35 -0400 Original-Received: by laas.laas.fr (8.13.1/8.13.4) with SMTP id j8TFaO5O004333; Thu, 29 Sep 2005 17:36:26 +0200 (CEST) Original-To: Vorfeed Canal X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 8 =?iso-8859-1?Q?Vend=E9miaire?= an 214 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.laas.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: powerpc-unknown-linux-gnu Mail-Followup-To: Vorfeed Canal , guile-user@gnu.org In-Reply-To: <6efab235050928131950e30e8c@mail.gmail.com> (Vorfeed Canal's message of "Thu, 29 Sep 2005 00:19:34 +0400") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang at CNRS-LAAS 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:4799 Archived-At: Hi Vorfeed, Vorfeed Canal writes: > 4. Actual contents of default directory list is not important. Only > two requirements: > A. It must not be empty - this way there are place to put default > libraries like readline. > B. It must be modifyable at runtime - this way complex program (like > Gnumeric or > Gnucash) can keep it's private libraries private and not pollute > default directory. Right. > In short: do not bother too much with understanding of my default > locations choice. Sure. So, I'm all in favor of having your patch (or something equivalent) applied. I guess you'll need to /kindly/ ask the developers for further reviewing and see what needs to be done so that it can actually be applied. > I did so as well, but surprisingly it's VERY minor issue: since it's > determined by GUILE_SITE_DIR and then by guile-config you can change > this default quite easily WITHOUT changing third-part extensions code! This is true since `GUILE_SITE_DIR' is already widely used. In fact, the right way to do it would probably be to have: 1. `%site-dir' (and obviously `GUILE_SITE_DIR') return `${datadir}/guile/MAJOR.MINOR/site'; 2. `%load-path' include both `${datadir}/guile/MAJOR.MINOR/site' _and_ `${datadir}/guile/site' (in this order). > Nope. You *can* *not* use them to solve (1). Trivial REAL WORLD > sample: university system where you can only install stuff in your own > home directory. Yes you can: have third-party C libraries use Guile's version info. IOW, add `-version-info $LIBGUILE_INTERFACE_CURRENT:$LIBGUILE_INTERFACE_REVISION:$LIBGUILE_INTERFACE_AGE' to your LDFLAGS. However, this would not permit extension developers to use `-version-info' for their own versioning purposes, so it sucks. > Yes, it'd be quite nice to allow both (1) and (2). But! > 1. It'll require major redesign or libtool (actual shared library is > versioned, but .la file is not). I don't think so but that discussion belongs to `libtool@'. > 2. Crude yet effective substitute usually enough: just add something > like "v2" to name of extension (like glib vs glib2). Not elegant but > it works... Remember: that's what `libguile-readline' already does. You might want to re-read your email answer to my suggesting such workarounds. :-) > In fact I'm not even sure this problem need solution! Think about it: > if we'll allow this we should allow two version of, for example (web > serialize) module. This means we'll be forced to develop some > versioning for scheme modules as well. A lot of work for unknown > benefit: in RARE cases where you really need two versions of the same > module you can cope with %load-path/%load-libpath tricks. "Lack of vision" you said earlier, right? I believe Scheme module versioning would be beneficial, although I have lived without it so far. Anyway, a quite straightforward solution (at first sight, at least) would be something like: (define-module (my-module) #:version/current 2 #:version/age 1 #:version/revision 4) And: (use-modules ((my-module) #:interface 1)) This would look for `my-module.scm' in the directories of `%load-path' and only import bindings from the first one (for instance) that implements version 1 of the interface, in pure Libtool style. And AFAICS, this wouldn't introduce any compatibility issue: both versioned and unversioned modules and module users could peacefully coexist. That may add some overhead in the rare case where a significant number of different versions of a module are available, since Guile needs to load each module before knowing whether it matches the constraint. Hmm... In fact, that may be much more complicated than it seems since `resolve-module' relies on `nested-ref' to find a module, and since there can only be one module bound to a given name... Thanks, Ludovic. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user