From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Greg Troxel Newsgroups: gmane.lisp.guile.user Subject: Re: Modified load-path proposal Date: 15 Oct 2005 11:40:39 -0400 Message-ID: References: <878xwx5ld2.fsf@ossau.uklinux.net> <8764s0a7e6.fsf@laas.fr> <8764rzj8py.fsf@ossau.uklinux.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1129391023 25121 80.91.229.2 (15 Oct 2005 15:43:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 15 Oct 2005 15:43:43 +0000 (UTC) Cc: Guile Users Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Oct 15 17:43:42 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EQo9O-000671-SM for guile-user@m.gmane.org; Sat, 15 Oct 2005 17:40:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EQo9O-0004H6-7N for guile-user@m.gmane.org; Sat, 15 Oct 2005 11:40:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EQo9J-0004G0-VN for guile-user@gnu.org; Sat, 15 Oct 2005 11:40:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EQo9J-0004FB-6g for guile-user@gnu.org; Sat, 15 Oct 2005 11:40:41 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EQo9J-0004Ez-1r for guile-user@gnu.org; Sat, 15 Oct 2005 11:40:41 -0400 Original-Received: from [192.1.100.210] (helo=fnord.ir.bbn.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EQo9J-0000E8-4l for guile-user@gnu.org; Sat, 15 Oct 2005 11:40:41 -0400 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id ED5C85286; Sat, 15 Oct 2005 11:40:39 -0400 (EDT) Original-To: Neil Jerram In-Reply-To: <8764rzj8py.fsf@ossau.uklinux.net> Original-Lines: 125 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 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:4851 Archived-At: before deciding about tags and descriptions, I think we need to be clearer on the semantics of these directories and why they'd be used. Let me take a stab at it, and I'm sure I'll leave out other's use cases. $(guileprefix)/share/guile top-level place within guile's prefix. currently has slib on NetBSD pkgsrc (symlink to /usr/pkg/share/slib) and slibcat file. $(guileprefix)/share/guile/site unclear why this is used rather than above, unless it's for sysadmin-managed stuff within guile's prefix rather than pkg-managed. On NetBSD pkgsrc database (ttn's guile-pg) lives here. $(guileprefix)/share/guile/1.6 Currently, stuff that is actually part of guile; I haven't seen other packages install stuff here. $(otherprefix)/share/guile probably where to put generic non-pkg-managed stuff, although that raises the issue of why a different prefix was used, but pkg systems may want to do this $(otherprefix)/share/guile/site non-pkg-managed stuff, done by group sysadmin. But, it seems likely that the use of otherprefix serves the purpose of site. A related point is whether it is ok to install two versions of guile in the same prefix. It seems that at least some things conflict, and this really doesn't work. NetBSD pkgsrc has support for 1.4 and 1.6 at the moment, with 1.6 default and 1.4 as guile14. guile14 is built with /usr/pkg/guile/1.4, so it's in a totally different place, and things that use it (not too many now) link there. So, if we can't install two guiles in the same prefix (which is fine; prefixes are fairly cheap), then it makes sense to declare that the 1.6 subdir is for things that are part of guile (meaning built from the distribution). Packages built against 1.6 would record a dependency, and you'd expect to have to rebuild them or get a version built against 1.8 later, just like packages built against anything else with a possibly changing ABI. Also, it could well be that the whole 'site' notion is outdated. This made sense back in the days of 4.3BSD, but with packaging systems doesn't so much, especially since the right thing to do is to have a separate prefix from the packaging system. So, my proposal is: $(guileprefix)/share/guile This is where pkg-managed modules should go. Those that think it is reasonable for programs configured with other prefixes should put them here, unless their package system says they should somehow keep non-pkg-managed stuff separate. $(guileprefix)/share/guile/site Historic/deprecated. Created by guile, but nothing put in it. If someone is using non-pkg-managed stuff across multiple machines, perhaps they should put it here. If someone is using non-pkg-managed programs, but using the 'put in guile's prefix' approach, perhaps all that stuff can go here so the non-managed stuff (viewed as turds by things like pkg_admin check to find unregistered files) will all be in one place. Thus this should perhaps be the default for macros called to ask for guile's prefix. $(guileprefix)/share/guile/1.6 As it is now: files that are part of guile. Others are strongly discouraged from putting anything there. $(guileprefix)/share/guile/local This would be like the old local vs. site. There seems to be little need. The 'add arbitrary dirs' scheme would support this, but guile should just ignore this and not mention it or put it in my default. $(otherprefix)/share/guile This is where I'd put modules installed aftetr configuring for another prefix. Whether this is site or local can be encoded in otherprefix. Adding a 1.6/1.8 dir won't fully solve the API/ABI compat issue, and doing it halfway will lead to trouble Then, the GUILE_SCHEME_DIR macro should take a token which is either guile-prefix own-prefix and return one of (depending on how we feel about protecting pkg systems from people who want to install non-managed stuff in them) $(guileprefix)/share/guile $(guileprefix)/share/guile/site or $(otherprefix)/share/guile Optionally, one should be able to specify either a replacement for share/guile or further components, perhaps when using either guile-prefix or own-prefix, and this should then generate or enable code to hook the dir into guile's load-path at make install time. So, I think my cross-product idea was not so good - the current 3 places are a bit messy/historic rather than really the right thing to do. -- Greg Troxel _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user