From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludovic.courtes@laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.user Subject: Re: Modified load-path proposal Date: Mon, 17 Oct 2005 10:04:11 +0200 Organization: LAAS-CNRS Message-ID: <87ach8bmdg.fsf@laas.fr> 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 1129541773 9034 80.91.229.2 (17 Oct 2005 09:36:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 17 Oct 2005 09:36:13 +0000 (UTC) Cc: Guile Users , Neil Jerram Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Oct 17 11:36:11 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ERROV-0001uD-D5 for guile-user@m.gmane.org; Mon, 17 Oct 2005 11:34:59 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ERROU-0002Ui-Js for guile-user@m.gmane.org; Mon, 17 Oct 2005 05:34:58 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ERQ65-0007Wa-Gd for guile-user@gnu.org; Mon, 17 Oct 2005 04:11:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ERQ51-000708-OT for guile-user@gnu.org; Mon, 17 Oct 2005 04:10:48 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ERQ1o-0005sm-LL for guile-user@gnu.org; Mon, 17 Oct 2005 04:07:29 -0400 Original-Received: from [140.93.0.15] (helo=laas.laas.fr) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1ERQ1o-0002oY-CD for guile-user@gnu.org; Mon, 17 Oct 2005 04:07:28 -0400 Original-Received: by laas.laas.fr (8.13.1/8.13.4) with SMTP id j9H87PW9026612; Mon, 17 Oct 2005 10:07:26 +0200 (CEST) Original-To: Greg Troxel X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 26 =?iso-8859-1?Q?Vend=E9miaire?= an 214 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.laas.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: powerpc-unknown-linux-gnu Mail-Followup-To: Greg Troxel , Neil Jerram , Guile Users In-Reply-To: (Greg Troxel's message of "15 Oct 2005 11:40:39 -0400") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang at CNRS-LAAS 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:4855 Archived-At: Hi, Greg Troxel writes: > 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. I don't think we should reason about installation directories in terms of packaging-system-managed vs. human-managed installations. I think the packaging system is just a special case of the "human-managed installation". However, packaging systems do provide an important installation pattern that has to be made possible to use. Looking at your proposal, I don't see why modules installed by a packaging system would end up in a different directory than modules installed "by hand". When I install a C program, whether "I" really refers to me or to a packaging system, I can specify installation directories with a very fine grain. In fact, maybe we should just mimic Autoconf/Automake and the GNU Standards[0] by (i) identifying exactly what the various installation directories we care about are, (ii) ensuring that they can be configured at installation-time, and (iii) make sure there's a way for Guile to know about them. The good thing is that this is policy-neutral. I guess the Guile-specific installation directories, for any given Guile module set (I'm not talking about modules that come with Guile), are: - `guileschemedir', which is where Guile Scheme source files should get installed; by default, this could be `/usr/share/guile/MAJOR.MINOR'; - `guilelibdir', which is where C libraries (glue code, wrappers, etc.) that come with a module should go; by default, this could be `/usr/local/lib'; - `guileobjectdir', which is where we'd put byte-compiled code if we had a working VM. ;-) At `make install'-time, we'd still need to use a mechanism like the one Neil proposed in order to `add-load-path $(guileschemedir)'. We might actually want to do this also for C libraries. [BTW, Neil's proposed `config.scm' is not unlike `ld.so.conf' (or equivalent) for C code.] >>From the user's view point, this wouldn't be any different from what is done when installing C programs: $ ./configure --bindir=/usr/bin --guileschemedir=/there \ --guilelibdir=/usr/share/lib/guile/2.3 In summary, if we look at Neil's `config.scm', it really cares about `guileschemedir' (or `load-path'), and that's it. So it might be possible to make it contain just a simple list of directories. OTOH, it might be a good idea to make it aware of `guilelibdir'. This way, if Guile is able to load a `.scm' file, it would _always_ be able to load the shared object it opens via `dynamic-link', no matter what LTDL_LIBRARY_PATH and friends look like. Hope this makes some sense, Ludovic. [0] http://www.gnu.org/prep/standards/html_node/Directory-Variables.html#Directory-Variables _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user