From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.devel Subject: Re: packaging the add-on libs... Date: Thu, 10 Oct 2002 10:37:20 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <87hefucnkf.fsf@raven.i.defaultvalue.org> References: <87vg4aevgx.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1034264673 20721 127.0.0.1 (10 Oct 2002 15:44:33 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 10 Oct 2002 15:44:33 +0000 (UTC) Cc: guile-devel@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17zfUF-0005Nj-00 for ; Thu, 10 Oct 2002 17:44:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17zfO2-0003Xx-00; Thu, 10 Oct 2002 11:38:06 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17zfNL-00030l-00 for guile-devel@gnu.org; Thu, 10 Oct 2002 11:37:23 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17zfNK-00030V-00 for guile-devel@gnu.org; Thu, 10 Oct 2002 11:37:23 -0400 Original-Received: from n66644228.ipcdsl.net ([66.64.4.228] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17zfNJ-00030O-00 for guile-devel@gnu.org; Thu, 10 Oct 2002 11:37:21 -0400 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 0591ABD92; Thu, 10 Oct 2002 10:37:21 -0500 (CDT) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id EDA847B9; Thu, 10 Oct 2002 10:37:20 -0500 (CDT) Original-To: Greg Troxel In-Reply-To: (Greg Troxel's message of "10 Oct 2002 08:51:24 -0400") Original-Lines: 48 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-pc-linux-gnu) Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1515 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1515 Greg Troxel writes: > Putting the guile version in the name makes sense to me, and I'd go > so far as to think about making libguile.a be libguile16.a. (we'd probably want to use libguile12, not 16, unless you're talking about some future version, or unless we're planning to change guile's actual version number to track libguile's) I've been wondering about this myself -- you'd also have libguile12.so which would make it much easier to install multiple libguileX-dev packages, but we'd still have to do something about the headers. Perhaps /usr/include/guile/1.6. > Given how many things link to guile 1.4 (e.g. gnomeish stuff), it > seems critical to make it easy for package systems to install both > guile14 and guile16, and that therefore these must have totally > disjoint sets of files, with the possible exception of the > guile-config link to guile16-config. A nice guile.m4 to find the > 'right' version might also be an exception. I'm planning to allow something like this on debian systems, though as mentioned I haven't decided on all the details yet, with whether or not we can/should allow multiple development version packages to be installed at the same time being an open question. > It's kludgy for packagers to add this, and causes extra differences, > where if guile itself does it, it is just the way the world is and > will be the same everywhere. I'm inclined to agree here. > On the other hand, putting all the dependent libs in > $(prefix)/libexec/guile/1.6/ also seems quite sensible to me, as long > as they are dlopened with an absolute path and no one is asked to put > this in LD_LIBRARY_PATH :-) Following the path of the P crowd seems > somewhat sensible, especially if there hasn't been large amounts of > pain from that approach. This still won't work if people are supposed to be allowed to link directly against these libs, and they are (at least not without -rpath, etc.) -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel