From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Vorfeed Canal Newsgroups: gmane.lisp.guile.user Subject: Re: Managing Guile and extensions versions Date: Thu, 29 Sep 2005 20:30:03 +0400 Message-ID: <6efab23505092909302c336ac0@mail.gmail.com> 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> <871x3728he.fsf@laas.fr> Reply-To: Vorfeed Canal 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 1128011758 20476 80.91.229.2 (29 Sep 2005 16:35:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 29 Sep 2005 16:35:58 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Sep 29 18:35:53 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EL1Nm-0008H5-7D for guile-user@m.gmane.org; Thu, 29 Sep 2005 18:35:42 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EL1Nk-0004gN-PQ for guile-user@m.gmane.org; Thu, 29 Sep 2005 12:35:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EL1MZ-0004K6-LN for guile-user@gnu.org; Thu, 29 Sep 2005 12:34:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EL1MY-0004JU-L0 for guile-user@gnu.org; Thu, 29 Sep 2005 12:34:26 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EL1MY-0004IN-7h for guile-user@gnu.org; Thu, 29 Sep 2005 12:34:26 -0400 Original-Received: from [72.14.204.205] (helo=qproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EL1IK-0006zf-E5 for guile-user@gnu.org; Thu, 29 Sep 2005 12:30:04 -0400 Original-Received: by qproxy.gmail.com with SMTP id p36so70354qba for ; Thu, 29 Sep 2005 09:30:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jhJE+zgbgpmwV/gxXIFa1MdyVm4OpO+CbgMK0pA5rVNz3Ls00eAiBLIib0gvSmk7NIdbtlwPCLnsHdli/5HfF8sg3JwSJUaRI/FD8HFb64Kl0RctZjlKWVBmX1V7+VsdCzbKJWKUgSOd3LdYCF7rzoWzQoXxXV63a5rYYY3Fi9s= Original-Received: by 10.65.156.14 with SMTP id i14mr407287qbo; Thu, 29 Sep 2005 09:30:03 -0700 (PDT) Original-Received: by 10.65.100.16 with HTTP; Thu, 29 Sep 2005 09:30:03 -0700 (PDT) Original-To: Vorfeed Canal , guile-user@gnu.org In-Reply-To: <871x3728he.fsf@laas.fr> Content-Disposition: inline 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:4800 Archived-At: On 9/29/05, Ludovic Court=E8s wrote: > > 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. > Where are how should I do this ? I was under impression that this list is exactly where such changes must be discussed. > > 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). > ...and since GUILE_SITE_DIR is already used by extensions developers it can be done by Debian, Gentoo or RedHat packagers. No need to lump different solutions together. > > 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_INTERF= ACE_AGE' > to your LDFLAGS. > How can it solve ANYTHING ? Guile WILL NOT scan anything besides /lib and /usr/lib (in that order) - even if you'll install it in /home/canal/my-guile ! Yes, you can play with LTDL_LIBRARY_PATH and LD_LIBRARY_PATH and do some other hacks - but this is hardly "clean solution for the problem". And once GUILE can load libraries from /home/canal/my-guile/lib you can use the same mechanism to solve multiple installations problem. > However, this would not permit extension developers to use > `-version-info' for their own versioning purposes, so it sucks. > See above: even with `-version-info' you still must alter libltdl search path and if you've done this you can use `-version-info' for some other purpose. > > 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. :-) > Not really - you can only use libguile-readline with the same version of guile, so it's solution for the first probem (and it does not really work as I've shown earlier). > > 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? > Nope. Just simple work/benefits check. [some rants are skipped] > 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... There are a lot of problems to be solved to make versioned modules usable. While idea in general is not bad it'll require deep rework of Guile internals, this is not 2-3 hours hack! So this is the case where you can safely blame lack of manpower. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user