From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.devel Subject: Re: dynamic argv0 relocation Date: Fri, 10 Jun 2005 22:03:14 -0400 Message-ID: References: <87zmty4b0v.fsf@peder.flower> <87ll5hx4py.fsf@zip.com.au> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1118455840 4222 80.91.229.2 (11 Jun 2005 02:10:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 11 Jun 2005 02:10:40 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Jun 11 04:10:31 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DgvS8-000711-4b for guile-devel@m.gmane.org; Sat, 11 Jun 2005 04:10:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DgvU4-0004P8-WE for guile-devel@m.gmane.org; Fri, 10 Jun 2005 22:12:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DgvTS-0004J5-RS for guile-devel@gnu.org; Fri, 10 Jun 2005 22:11:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DgvTM-0004F2-De for guile-devel@gnu.org; Fri, 10 Jun 2005 22:11:44 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DgvTM-0004Df-9W for guile-devel@gnu.org; Fri, 10 Jun 2005 22:11:44 -0400 Original-Received: from [207.172.4.63] (helo=smtp04.mrf.mail.rcn.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DgvLf-000539-PW for guile-devel@gnu.org; Fri, 10 Jun 2005 22:03:47 -0400 Original-Received: from 65-78-24-4.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO raeburn.org) (65.78.24.4) by smtp04.mrf.mail.rcn.net with ESMTP; 10 Jun 2005 22:03:16 -0400 X-IronPort-AV: i="3.93,191,1115006400"; d="scan'208"; a="45749627:sNHT23734250" Original-Received: from [18.18.1.76] (KEN-WIRELESS.MIT.EDU [18.18.1.76]) by raeburn.org (8.12.11/8.12.11) with ESMTP id j5B23Ews000852; Fri, 10 Jun 2005 22:03:14 -0400 (EDT) In-Reply-To: <87ll5hx4py.fsf@zip.com.au> Original-To: guile-devel@gnu.org X-Mailer: Apple Mail (2.622) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:5096 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:5096 On Jun 10, 2005, at 17:49, Kevin Ryde wrote: > No offence, but it sounds very dubious to me. These things are meant > to be settled at the "make all" build stage. (The gnu standards have > bits about that.) Normally, it is, yes, if the application has to have that knowledge pre-compiled in. But does it have to? It's better still if it just doesn't need to do that. I'd like to bring up a variant on the package-installation issue that Jan raised: Mac OS X applications. An app is represented to the user as an object. It can be moved around, opened (launched), or deleted, like any other object. It just happens that its representation in the file system is a directory hierarchy with certain standard components, and some application-specific components. The "Emacs" app, for example, includes all of the content of a normal Emacs installation buried under Emacs.app/Contents/MacOS and Emacs.app/Contents/Resources. My copy lives in /Applications, but the string "/Applications" doesn't seem to live in the executable; it figures out where it is. I can move it to my desktop and launch it from there, and it still works just fine. Or I can copy it to an external drive or a network drive. If I had a copy stored in a networked home directory for use from multiple machines, I could copy the *same* application to local disk on my office workstation and use it locally, without having to rebuild. It's *very* nice to be able to copy/move an application from one place to another or rename it, like you could do for any other object, and have it Just Work. (And it's not unheard of in other GNU software. See GCC's GCC_EXEC_PREFIX environment variable, for example.) I could see, maybe, creating a Guile.app which starts up a terminal-like window with a Guile interpreter running, or something like that. Menu items for "load Scheme file", "new interpreter", etc. With all the Scheme support files buried inside, it too could be treated as a standalone object. I think the thing that makes this case tricky is the Guile library. The other cases of this sort of thing that I'm familiar with are all applications, and don't have to worry about library search paths, or being used from within a different package located someplace else. (And in the case of Mac OS X, it appears that the "launch" protocol includes invoking the executable via an absolute path name and with some magic arguments.) Unfortunately, I don't have any good ideas for how to make the library code path-independent without introducing environment variables or something like that which the user would have to manually set. Ken _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel