Re: dynamic argv0 relocation

[Ken Raeburn <raeburn@raeburn.org>]

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