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 00:19:34 +0400 Message-ID: <6efab235050928131950e30e8c@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> 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 1127939022 10903 80.91.229.2 (28 Sep 2005 20:23:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 28 Sep 2005 20:23:42 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Sep 28 22:23:41 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EKiQa-00034i-Qg for guile-user@m.gmane.org; Wed, 28 Sep 2005 22:21:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EKiQa-0003gW-84 for guile-user@m.gmane.org; Wed, 28 Sep 2005 16:21:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EKiQU-0003f2-78 for guile-user@gnu.org; Wed, 28 Sep 2005 16:21:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EKiQS-0003e5-MH for guile-user@gnu.org; Wed, 28 Sep 2005 16:21:13 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EKiQS-0003dN-Gl for guile-user@gnu.org; Wed, 28 Sep 2005 16:21:12 -0400 Original-Received: from [72.14.204.205] (helo=qproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EKiOt-0004JS-R9 for guile-user@gnu.org; Wed, 28 Sep 2005 16:19:36 -0400 Original-Received: by qproxy.gmail.com with SMTP id e14so540518qbc for ; Wed, 28 Sep 2005 13:19:34 -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=lWH9XsZFL3vraLFalTv2Z1wWkPezKvxck5+O3suXjAL5a8yOfKoy6nA7vlPyfL7EgNLqrCcisJmvZp7mmlcnynoig5GrTAezymhdt0SVMvSN4lv5M+H+NTKxw7QYivQU0F6MlX8X/Hf7HbwVmtoS9pLJXd8oC0LpOzzPBU51vc0= Original-Received: by 10.65.98.20 with SMTP id a20mr24899qbm; Wed, 28 Sep 2005 13:19:34 -0700 (PDT) Original-Received: by 10.65.100.16 with HTTP; Wed, 28 Sep 2005 13:19:34 -0700 (PDT) Original-To: Vorfeed Canal , guile-user@gnu.org In-Reply-To: <87d5mtis5l.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:4797 Archived-At: On 9/28/05, Ludovic Court=E8s wrote: > Hi, > > Vorfeed Canal writes: > > > Of course it must - how else can it load them ? With my patch it knows > > about few default places and can be instructed about other places in > > nice shemely way. > > Yes, your patch seems to be one possible solution. However, why not use > `pkglibdir' (versionizing it) which you mentioned in earlier posts > instead of this new directory? > 1. I *am* using pkglibdir - take closer look on patch. 2. It's mostly matter of taste. A. Apache and PHP are using one directory B. Python and Ruby - two: one - for system packages and things installed with package manager anouther - for manually installed things, kinda /usr vs /usr/local C. Emacs - three: one - for bundled files one - for universal packages: /usr/share/emacs/site-lisp one for specific packages: vs /usr/share/emacs/21.4/site-lisp D. Perl - three but for different reasons: bundled things will go to /usr/lib/perl5/5.8.6/i686-linux package-installed things will go to /usr/lib/perl5/vendor_perl/5.8.6/i686-linux manually-installed - to /usr/lib/perl5/site_perl/5.8.6/i686-linux 3. Guile itself already have %load_path for scheme_extensions and it looks like this: $ guile -c '(display %load-path)' (/usr/share/guile/site /usr/share/guile/1.7 /usr/share/guile) I think the right idea is to keep list similar in structure. 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. In short: do not bother too much with understanding of my default locations choice. As long as there are some macros defined guile.m4 suitable for putting in configure.ac I (as extension writer) will be happy. Exact place where my libraries will be kept not as important: configure will determine place, Makefile.am will put libraries there, guile will load them - I'm not really interested in such morbid details, just in the end result. Application writer is interested in configurability (I want to add my own private directory to the list and still keep the ability to load library from "standard place"), again: what is stored in "standard places list" is not interesting (as long as SOMETHING stored there). > The other thing needed, which you also mentioned earlier, is to have a > versionized site directory. I've actually always wondered why this one > was not versioned. > 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! And you already can call configure as GUILE=3D/usr/bin/guile-1.4 GUILE_CONFIG=3D/usr/bin/guile-config-1.4 GUILE_TOOLS=3D/usr/bin/guile_tools ./configure ... This means only architecture-depenent libraries generated by third-party modules can not be easily handled... > >> This is true I guess, because `dynamic-link' doesn't allow to specify > >> version info. _This_ is an issue and maybe this procedure could be > >> fixed by allowing the user to pass Libtool-like version information. > > > > This is one solution. And IMO not the best solution. > > That's a solution to one of the two problems, the two problems being: > > 1. Separating C libraries that are written for different versions of > Guile, allowing to have versions of the same extension written for > different Guile versions to coexist; > > 2. Allowing to have different versions of a given extension for a same > version of Guile. > > Your patch addresses (1). This `dynamic-link' thing could be used to > address (2). It could be used to address (1) instead, but certainly not > both of them. 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. > Anyway, we'd first need `libltdl' to allow for such things. > I started to ask the Libtool people about this: > http://lists.gnu.org/archive/html/libtool/2005-09/msg00118.html . > 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). 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... 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. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user