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: Release now? Date: Tue, 25 Feb 2003 20:27:16 -0600 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <873cmbpyij.fsf@raven.i.defaultvalue.org> References: <87of50tdcz.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1046226632 5842 80.91.224.249 (26 Feb 2003 02:30:32 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 26 Feb 2003 02:30:32 +0000 (UTC) Cc: Marius Vollmer 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 18nrL1-0001Vt-00 for ; Wed, 26 Feb 2003 03:30:27 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18nrKs-00008k-03 for guile-devel@m.gmane.org; Tue, 25 Feb 2003 21:30:18 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18nrKG-0008L6-00 for guile-devel@gnu.org; Tue, 25 Feb 2003 21:29:40 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18nrK3-0007gl-00 for guile-devel@gnu.org; Tue, 25 Feb 2003 21:29:29 -0500 Original-Received: from dsl093-098-016.wdc1.dsl.speakeasy.net ([66.93.98.16] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18nrHx-00064J-00 for guile-devel@gnu.org; Tue, 25 Feb 2003 21:27:17 -0500 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 457123B0; Tue, 25 Feb 2003 20:27:16 -0600 (CST) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 15BDDD10F3; Tue, 25 Feb 2003 20:27:16 -0600 (CST) Original-To: Greg Troxel In-Reply-To: (Greg Troxel's message of "25 Feb 2003 20:51:22 -0500") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) Original-cc: guile-devel@gnu.org Original-cc: Mikael Djurfeldt X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:1982 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1982 Greg Troxel writes: > This makes sense. But, I'd lean hard to trying not to change such > interfaces by adding new names and deprecating old procedures over time. > Also, I'm not sure this is causing us pain, and I somewhat lean in the > direction of only favoring complex mechanisms to avoid actual or > near-term expected pain. I think I tend to look at it as setting up infrastructure now that encourages people to do things that may save anguish later, but I can also see your point. Though I did have the semi-amusing idea of trying to make guile nearly all modules (which I think I've mentioned before), i.e. #!/usr/bin/guile-strap -s \ !# (use-modules (ice-9 core #:interface 6)) ... I think it's probably simpler and more obviously useful to just standardize our naming convention. I'm inclined to change the unstable tree to install guile as guile-X.Y from now on, along with all the other tools, and have an easily bypassable inst-hook (or similar) that sets up the default links: cd ${bindir} && ln -sf guile-X.Y guile I might also try to make another install target that didn't set up the links, perhaps "make install-no-convenience-links" or whatever. This would allow people to reliably start writing #!/usr/bin/guile-1.6 scripts, or maybe more portably #!/bin/sh exec guile-1.6 "$@" > If someone is unwilling to use -rpath and unwilling to use > LD_LIBRARY_PATH, then yes, guile's libs need to be in /usr/lib. guile > can be built with --prefix=/usr, so this is supported. This makes it > hard to have two versions unless all libs have versions in the names. > I'm not sure how hard it would be to make /usr/lib/libguile16.so.15 > and /usr/lib/libguile14.so.10 instead - and I'm not sure what it would > hurt. (An example is glib 1.2 and 2.0.) What do you think about my other suggestion? i.e. - put libguile.so.*, etc. in /usr/lib (i.e. ${libdir}) - put the libguile.so development symlinks (i.e. the ones -l uses) in /usr/lib/guile/VERSION - put the headers in /usr/include/guile/VERSION - require the use of guile-config and arrange for guile-config to spit out -I/usr/include/guile/VERSION and -L/usr/lib/guile/VERSION when appropriate So far this seems to me like it might solve the "allow multiple development versions to be installed" problem without requiring -rpath, LD_LIBRARY_PATH, or ld.so.conf modifications, but I haven't been thinking about it for long yet. If this *would* work, I can implement it in CVS, and adjust Debian accordingly... Basically gcc -lguile would find the libguile.so in /usr/lib/guile/VERSION/ via the -L argument from guile-X.Y-config, and would use that to embed the right SONAME into the app or lib being built. Then at runtime, the linker would find the newest suitable version, say libguile.so.12.0.1 in /usr/lib/. > But I wasn't talking about this - I meant compatibility at the > source/build level, not dynamically linking the new .so into an old > binary. The real pain has happened because one couldn't in general > take a program that built against guile 1.4 and just replace guile > with 1.6 and rebuild it from scratch. I won't argue that the 1.4 -> 1.6 transition was possibly somewhat jarring. While I still feel like many of those changes were worthwhile and will serve us well going forward, I think that we're likely to do that less often going forward. As Marius has mentioned, we'll be restoring a number of things in CVS that had already been removed in preparation for 1.8. > Thanks for thinking about this - I think it is critical to promoting > guile acceptance and use. You and I both :> Though guile's particular objectives do provide some fairly "challenging" constraints on the possible solutions. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel