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: 27 Feb 2003 14:25:09 -0500 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: <87of50tdcz.fsf@raven.i.defaultvalue.org> <873cmbpyij.fsf@raven.i.defaultvalue.org> <873cm9oe9k.fsf@raven.i.defaultvalue.org> <878yw1mukp.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 1046373998 24522 80.91.224.249 (27 Feb 2003 19:26:38 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 27 Feb 2003 19:26:38 +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 18oTfr-0006N8-00 for ; Thu, 27 Feb 2003 20:26:31 +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 18oTfx-00056e-05 for guile-devel@m.gmane.org; Thu, 27 Feb 2003 14:26:37 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18oTfT-0004r5-00 for guile-devel@gnu.org; Thu, 27 Feb 2003 14:26:07 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18oTfQ-0004pX-00 for guile-devel@gnu.org; Thu, 27 Feb 2003 14:26:05 -0500 Original-Received: from fnord.ir.bbn.com ([192.1.100.210]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18oTeX-0004LL-00 for guile-devel@gnu.org; Thu, 27 Feb 2003 14:25:09 -0500 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 40BFC864; Thu, 27 Feb 2003 14:25:09 -0500 (EST) Original-To: Rob Browning In-Reply-To: <878yw1mukp.fsf@raven.i.defaultvalue.org> Original-Lines: 149 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 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:2002 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2002 Though at least for end-users compiling using guile-config, I'd hope the transition would be rather painless. I think I'm almost convinced (and almost is enough) that's true. I don't really think that's feasible, at least not as the default. At least for most of the linux distributions (and I'd guess solaris, etc.) that would be in contravention of the FHS (and predecessors), and I would guess also the LSB. I just went and read parts of FHS, so I see your point on this. That said, GNU software supports letting the user choose the prefix, and we shouldn't lose that, but if our interpretion of where things belong under the prefix includes versioned subdirs that's OK. Also we're going to *have* to change the install location of the headers, i.e. /usr/include/guile/VERSION/, at least for normal autoconf style installs, i.e. FHS compliant installs since using /usr/include/libguile.h doesn't allow multiple dev versions to be installed. Either that or multiple prefixes, and I see that multiple prefixes are frowned upon by the FHS. Since there is no proposal on the table to remove the ability to use --prefix, that's not an issue. If what you're arguing for is in fact an "opt-style" install, then that's fine, but I think it'll have to be something that can be enabled rather than the default since it's my impression that FHS style layouts are the definite majority. I was asking for the current bebavior to be preserved unless someone asks for --version-dirs, which would put things in /usr/lib/guile/1.x instead of /usr/lib (and similarly for /usr/share, etc.). But I guess that really isn't necessary, as long as guile-config-using software can just rebuild and run. So I withdraw this objection. I think maybe I still don't have a good impression of what you're preferred solution is (and that's likely my fault) -- I'm not sure what the "prefixes" are here. I meant: guile14-src $ ./configure --prefix=/usr/pkg/guile/1.4 guile16-src $ ./configure --prefix=/usr/pkg/guile/1.6 guile18-src $ ./configure --prefix=/usr/pkg/guile/1.8 or perhaps one of them being the 'primary' and installed in /usr/pkg directly. But I see how this violate FHS and how people might not like it. And I realize it causes problems in a rpath-prohibited environment. Overall, I still feel like the changes I've proposed are a fairly small alteration to the current strategy, and seem to be likely to work everywhere. That's what's driving my immediate inclination. I may be overestimating their impact. Perhaps if you wrote down precisely what files would get installed in different places, and what extra symlinks would be made (and under what circumstances) this would all be clearer. I just looked through what is in the 1.6 pkg, and see a bunch of things. I'll list them and annotate with what I think you are proposing. Except that I don't get what you mean for libs, so I listed what came to me as I was doing this exercise. Then, it would be good to understand the ripple effects on e.g. having guile-gtk for two guile versions installed - can that just adopt the same scheme? bin/guile bin/guile-snarf bin/guile-config bin/guile-tools put in bin/guile/X.Y, and symlink one to bin/guile presumably the "I want the symlink in the standard place" is a configure option, so it can be assigned to the package denoted as primary by the package system maintainer. Use --primary-symlinks as the configure option, perhaps. include/libguile/__scm.h [...] include/guile/gh.h include/guile/srfi/srfi-4.h include/guile/srfi/srfi-13.h include/guile/srfi/srfi-14.h include/guile-readline/readline.h include/libguile.h put in include/guile/X.Y/{libguile/*,guile/*,libguile.h}, with no symlinks. people should be using guile-config/pkgconfig, so there is no need to have anything work unless the appropiate -I/usr/include/guile/1.4 is given. info/guile.info info/guile.info-1 [...] put in info/guile/X.Y/*, with symlinks from info if the --primary-symlinks option was given. This makes them all available and the primary obtained by default. lib/libguile.a lib/libguile.la lib/libguile.so lib/libguile.so.15 lib/libguile.so.15.0 lib/libguile-ltdl.a lib/libguile-ltdl.la lib/libguile-ltdl.so lib/libguile-ltdl.so.1 lib/libguile-ltdl.so.1.0 lib/libguilereadline-v-12.a lib/libguilereadline-v-12.la lib/libguilereadline-v-12.so lib/libguilereadline-v-12.so.15 lib/libguilereadline-v-12.so.15.0 lib/libguile-srfi-srfi-4-v-1.a lib/libguile-srfi-srfi-4-v-1.la lib/libguile-srfi-srfi-4-v-1.so lib/libguile-srfi-srfi-4-v-1.so.1 lib/libguile-srfi-srfi-4-v-1.so.1.0 lib/libguile-srfi-srfi-13-14-v-1.a lib/libguile-srfi-srfi-13-14-v-1.la lib/libguile-srfi-srfi-13-14-v-1.so lib/libguile-srfi-srfi-13-14-v-1.so.1 lib/libguile-srfi-srfi-13-14-v-1.so.1.0 put in lib/guile/X.Y symlinks for libguile.so.15/15.0 and other libs into lib/ symlinks for libguile.a/libguile.la (?) if --primary-symlinks never a symlink in lib for libguile.so itself err, now I realize this isn't what you mean. I think you have proposed putting the .sos with versions in $(prefix)/lib, and symlinks for libguile.so in the special link-time-only lib. But I don't understand where the .a and .la versions go - is the /usr/lib/guile/X.Y scheme primary, or not? With include files, it is primary, and it's only an accident of so naming that they don't collide for some cases. how about /usr/lib has no guile files, unless --lib-symlinks is given? Then the rpath users will have a clean separation, and those without rpath can pick up libguile.so.{9,10,15} from /usr/lib. share/aclocal/guile.m4 put in share/guile/1.4/aclocal/guile.m4 symlink in share/aclocal if --primary-symlinks share/guile/1.6/oop/goops/active-slot.scm [...] already versioned. No changes needed. So I realize now that I don't understand what you propose in terms of moving libraries. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel