From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Greg Troxel Newsgroups: gmane.lisp.guile.devel Subject: Re: Release now? Date: 25 Feb 2003 20:51:22 -0500 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: 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 1046224335 30663 80.91.224.249 (26 Feb 2003 01:52:15 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 26 Feb 2003 01:52:15 +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 18nqk1-0007yQ-00 for ; Wed, 26 Feb 2003 02:52:13 +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 18nqja-0005bQ-04 for guile-devel@m.gmane.org; Tue, 25 Feb 2003 20:51:46 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18nqjF-0005ap-00 for guile-devel@gnu.org; Tue, 25 Feb 2003 20:51:25 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18nqjD-0005ae-00 for guile-devel@gnu.org; Tue, 25 Feb 2003 20:51:24 -0500 Original-Received: from fnord.ir.bbn.com ([192.1.100.210]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18nqjD-0005aa-00 for guile-devel@gnu.org; Tue, 25 Feb 2003 20:51:23 -0500 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 01F787BE; Tue, 25 Feb 2003 20:51:22 -0500 (EST) Original-To: Rob Browning In-Reply-To: <87of50tdcz.fsf@raven.i.defaultvalue.org> Original-Lines: 104 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 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:1981 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1981 I'd tend to lean towards having a standard strategy like #:interface or maybe #:version for people to use. They can always ignore it and invent their own custom strategies using (use-modules (foo)) if they want. I'm open to being convinced otherwise, though. 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. FWIW, as far as I can tell, the only way we can allow compilation for multiple versions of guile is if we don't put the libs into /usr/lib with the other libraries. Either that, or we have to put our major version number into the library name. NetBSD's buildlink2 mechanism conses up a special tree to use for builds, and only puts the libs that are needed there. I don't know how this works for locating the right stuff at run-time, but it does rely heavily on -rpath. In fact we wouldn't be able to put *any* libguile.so into /usr/lib, otherwise *any* other package's foo-config script that put a -L/usr/lib on the gcc command line could cause us to get the wrong one, even if the gcc command line also contained the output of an invocation of guile-X.Y-config somewhere. I think this is a general problem of needing the specific -L/-R before the general locations. Another consideration (and perhaps everyone is still aware of) is that of -rpath. There are many who are opposed to it, and without it, you don't really have any way to put guile's libs anywhere but /usr/lib or similar... 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.) Perhaps I'm misunderstanding. If the soname hasn't changed, then you should be fine. If it has, then you have to recompile... Also, unless we can *prove* that nothing has changed in a way that would break backward compatibility, we have to change the soname with each major release. I would advocate bumping the .so # when there is a known incompatible change, but I see the playing it safe path as reasonable too. 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. Gnucash 1.6.8 is specified to only work with 1.4, for example. If everything could be built against 1.6, even if it did have to be recompiled (e.g. some functions are now macros that invoke compatibility calls) that would mean everything needed to be rebuilt, but that's just cpu time, not package pain, at least in the NetBSD pkgsrc view. One would just to to /usr/pkgsrc/lang/guile and type 'make update', and it would recursively delete and rebuild all that depended on guile. But because some programs can't (or are thought not to be able) to build with new guile, it was necessary to simultaneously support both. Also I guess we need to be clear what the C lib sonames mean. Do they also reflect the indirect "API" available from ice-9 via scm_c_eval? For example, if we had a function in ice-9 called (get-blarg) that returned `(,foo . ,bar), and we change it so that it returns `(,bar . ,foo), then do we have to change the libguile version number since since C code could access this via scm_c_eval? Perhaps, perhaps not, but I think we should figure this out and make a clear statement in the docs. A very good point. If we don't take the more strict view, then there needs to be an interface version accessible via a standard API. Or, perhaps we need to say "Don't do that." Add a new call, and then deprecate the old one, but don't change documented behavior lightly. As far as I can tell, this is always going to be true to some extent, though we should do our best to minimize it. I've seen it happen for perl and python regularly, and I'd expect our situation to be worse (and it is) because of our unique requirement that users be able to link directly to our libraries from C, and that of course leads to libs linked to libs linked to guile and the whole "indirect linkage to two versions of libguile" problem. > So, ensuring that 1.8 is a drop-in replacement for 1.6 would be good, If you mean drop-in as in "just requires a recompile of things linked against it", then I suspect that's quite possible. If you mean "doesn't even require recompile", then I at least somewhat doubt it. I meant just requiring a recompile. But, if the old so is present, with a different major verison, the old stuff should continue to work. Thanks for thinking about this - I think it is critical to promoting guile acceptance and use. Greg Troxel _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel