GNU bug report logs - #12123
relocatable installation

Previous Next

To reply to this bug, email your comments to 12123 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #1 received at quiet <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: quiet <at> debbugs.gnu.org
Subject: relocatable installation
Date: Thu, 02 Aug 2012 12:58:24 -0400

Package: emacs
Severity: wishlist
Version: 24.1

A --with-ns build can be built as a "relocatable app bundle".
(In fact it defaults to this, unless you configure with
--disable-ns-self-contained.)

In this mode, the --prefix option to configure is ignored.
`make install' constructs a directory nextstep/Emacs.app with contents
like this:

Emacs   # the executable
bin     # directory with user executables
etc
info
leim
libexec # directory with internal executables
lisp
man


A non-ns build could have the same feature (except the "Emacs" should go
in the bin/ directory and have a standard name).

It needs a few changes to various Makefile.ins (see the ns_appbindir etc
portions), as well as functions analogous to ns_load_path,
ns_etc_directory, and ns_exec_path.  For simplicity/consistency, these
should be renamed to eg reloc_load_path, etc. Then init_lread,
init_callproc_1, init_callproc should be changed accordingly.

Message #2 received at 12123-quiet <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 12123-quiet <at> debbugs.gnu.org
Subject: Re: relocatable installation
Date: Sat, 04 Aug 2012 14:09:23 -0400

See also http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11959#64

Message #5 received at 12123 <at> debbugs.gnu.org (full text, mbox):

From: chad <yandros <at> MIT.EDU>
To: 12123 <at> debbugs.gnu.org
Subject: bug#12123
Date: Fri, 5 Apr 2013 10:27:21 -0700

Web searching suggests approaches for several specific platforms
(GNU/Linux, FreeBSD, Solaris, macosx, and Windows) that might be
useful:

http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe

Message #8 received at 12123 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 12123 <at> debbugs.gnu.org
Subject: Re: bug#12123:
Date: Fri, 05 Apr 2013 13:32:02 -0400

chad wrote:

> Web searching suggests approaches for several specific platforms
> (GNU/Linux, FreeBSD, Solaris, macosx, and Windows) that might be
> useful:
>
> http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe

I don't think this is an issue. We've already got invocation-directory,
which is probably good enough in 99.9+% of cases. Unless people do
obscure things to hide the executable, in which case they just don't get
to use a relocatable Emacs.

Message #11 received at 12123 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: chad <yandros <at> MIT.EDU>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12123 <at> debbugs.gnu.org
Subject: Re: bug#12123:
Date: Fri, 05 Apr 2013 20:48:33 +0300

> From: chad <yandros <at> MIT.EDU>
> Date: Fri, 5 Apr 2013 10:27:21 -0700
> 
> Web searching suggests approaches for several specific platforms
> (GNU/Linux, FreeBSD, Solaris, macosx, and Windows) that might be
> useful:
> 
> http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe

The Windows method mentioned there is exactly what Emacs already uses
on Windows.

Anyway, I see that gnulib has a progreloc module whose purpose is to
make program relocatable.  Perhaps Paul (CC'ed) could import it and
use it in callproc.c to do what Stefan suggested.

Message #14 received at 12123 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12123 <at> debbugs.gnu.org, chad <yandros <at> MIT.EDU>
Subject: Re: bug#12123:
Date: Fri, 05 Apr 2013 23:47:28 -0700

On 04/05/2013 10:48 AM, Eli Zaretskii wrote:
> Perhaps Paul (CC'ed) could import it and
> use it in callproc.c to do what Stefan suggested.

That sounds like it might work, yes, but it's
nontrivial.  I've never used that module myself.

Message #17 received at 12123 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12123 <at> debbugs.gnu.org, yandros <at> MIT.EDU
Subject: Re: bug#12123:
Date: Sat, 06 Apr 2013 11:22:46 +0300

> Date: Fri, 05 Apr 2013 23:47:28 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: chad <yandros <at> MIT.EDU>, 12123 <at> debbugs.gnu.org
> 
> On 04/05/2013 10:48 AM, Eli Zaretskii wrote:
> > Perhaps Paul (CC'ed) could import it and
> > use it in callproc.c to do what Stefan suggested.
> 
> That sounds like it might work, yes, but it's
> nontrivial.  I've never used that module myself.

Then perhaps we could just borrow the ideas from progreloc.c.

Message #20 received at 12123 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12123 <at> debbugs.gnu.org, yandros <at> MIT.EDU
Subject: Re: bug#12123:
Date: Sat, 06 Apr 2013 13:35:09 -0700

On 04/06/2013 01:22 AM, Eli Zaretskii wrote:
> Then perhaps we could just borrow the ideas from progreloc.c.

That sounds like more work than using the Gnulib module,
I expect.

Message #23 received at 12123 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12123 <at> debbugs.gnu.org, yandros <at> MIT.EDU
Subject: Re: bug#12123:
Date: Sun, 07 Apr 2013 05:42:08 +0300

> Date: Sat, 06 Apr 2013 13:35:09 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: yandros <at> MIT.EDU, 12123 <at> debbugs.gnu.org
> 
> On 04/06/2013 01:22 AM, Eli Zaretskii wrote:
> > Then perhaps we could just borrow the ideas from progreloc.c.
> 
> That sounds like more work than using the Gnulib module,
> I expect.

Not necessarily.  progreloc.c is relatively short, and is really just
a series of platform-dependent methods to find the absolute file name
of the running program.  The MS-Windows method used there is already
being used in Emacs, and most of the infrastructure for relocating a
directory is already in place.

Message #26 received at 12123 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12123 <at> debbugs.gnu.org, yandros <at> MIT.EDU, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#12123:
Date: Sun, 07 Apr 2013 14:32:51 -0400

Eli Zaretskii wrote:

>> > Then perhaps we could just borrow the ideas from progreloc.c.
>> 
>> That sounds like more work than using the Gnulib module,
>> I expect.
>
> Not necessarily.  progreloc.c is relatively short, and is really just
> a series of platform-dependent methods to find the absolute file name
> of the running program.  The MS-Windows method used there is already
> being used in Emacs, and most of the infrastructure for relocating a
> directory is already in place.

I must be missing something, because AFAICS, invocation-directory has
already solved this problem. What cases are not already handled that are
relevant and need extra code adding from progreloc.c?

Message #29 received at 12123 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 12123 <at> debbugs.gnu.org, yandros <at> MIT.EDU, eggert <at> cs.ucla.edu
Subject: Re: bug#12123:
Date: Sun, 07 Apr 2013 22:06:32 +0300

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>,  12123 <at> debbugs.gnu.org,  yandros <at> MIT.EDU
> Date: Sun, 07 Apr 2013 14:32:51 -0400
> 
> I must be missing something, because AFAICS, invocation-directory has
> already solved this problem. What cases are not already handled that are
> relevant and need extra code adding from progreloc.c?

Code in emacs.c that sets invocation-directory relies on argv[0] to
either be an absolute file name, or relative to cwd, or a base name
without leading directories that can be found on PATH.  But on Posix
platforms, argv[0] can be anything, while on Windows argv[0] might be
neither absolute nor on PATH.

progreloc.c solves this in platform-specific ways.  E.g., on
GNU/Linux, it looks at /proc/PID/exe.

Message #32 received at 12123 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rgm <at> gnu.org
Cc: 12123 <at> debbugs.gnu.org, yandros <at> MIT.EDU, eggert <at> cs.ucla.edu
Subject: Re: bug#12123:
Date: Sun, 07 Apr 2013 22:42:11 +0300

> Date: Sun, 07 Apr 2013 22:06:32 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 12123 <at> debbugs.gnu.org, yandros <at> MIT.EDU, eggert <at> cs.ucla.edu
> 
> Code in emacs.c that sets invocation-directory relies on argv[0] to
> either be an absolute file name, or relative to cwd, or a base name
> without leading directories that can be found on PATH.

Btw, even if these conditions _are_ true, I still don't see how can we
find /usr/libexec/emacs/VERSION/CONFIG/, /usr/share/emacs/VERSION/lisp/
using the fact that Emacs was invoked from /usr/bin/.  Which part of
the code knows about VERSION and CONFIG part and looks for them?  All I
see is that we look for lib-src and etc, but that's only good to detect
that we are being run from the build directory, not from where we are
installed.  What am I missing?

Message #35 received at 12123 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12123 <at> debbugs.gnu.org, yandros <at> MIT.EDU, eggert <at> cs.ucla.edu
Subject: Re: bug#12123:
Date: Sun, 07 Apr 2013 22:00:49 -0400

Eli Zaretskii wrote:

> Btw, even if these conditions _are_ true, I still don't see how can we
> find /usr/libexec/emacs/VERSION/CONFIG/, /usr/share/emacs/VERSION/lisp/
> using the fact that Emacs was invoked from /usr/bin/.  Which part of
> the code knows about VERSION and CONFIG part and looks for them?  All I
> see is that we look for lib-src and etc, but that's only good to detect
> that we are being run from the build directory, not from where we are
> installed.  What am I missing?

Well yes, that's the point of this report. No-one has implemented a
relocatable Emacs installation for general POSIX platforms. Solving
those problems is part of it. A relocatable Emacs would not be installed
as you describe above, it would (I imagine) be installed similar to the
way the NS build is, under a single top-level directory.

Message #38 received at 12123 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12123 <at> debbugs.gnu.org, yandros <at> MIT.EDU, eggert <at> cs.ucla.edu
Subject: Re: bug#12123:
Date: Sun, 07 Apr 2013 22:02:37 -0400

Eli Zaretskii wrote:

> Code in emacs.c that sets invocation-directory relies on argv[0] to
> either be an absolute file name, or relative to cwd, or a base name
> without leading directories that can be found on PATH.

As I said, I think this will cover 99.9+% of cases. Anyone trying to do
anything more obscure just doesn't get to use a relocatable Emacs, IMO.
But of course if you want a totally general solution, go ahead.

Message #41 received at 12123 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 12123 <at> debbugs.gnu.org, yandros <at> MIT.EDU, eggert <at> cs.ucla.edu
Subject: Re: bug#12123:
Date: Mon, 08 Apr 2013 05:44:39 +0300

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: 12123 <at> debbugs.gnu.org,  yandros <at> MIT.EDU,  eggert <at> cs.ucla.edu
> Date: Sun, 07 Apr 2013 22:00:49 -0400
> 
> Eli Zaretskii wrote:
> 
> > Btw, even if these conditions _are_ true, I still don't see how can we
> > find /usr/libexec/emacs/VERSION/CONFIG/, /usr/share/emacs/VERSION/lisp/
> > using the fact that Emacs was invoked from /usr/bin/.  Which part of
> > the code knows about VERSION and CONFIG part and looks for them?  All I
> > see is that we look for lib-src and etc, but that's only good to detect
> > that we are being run from the build directory, not from where we are
> > installed.  What am I missing?
> 
> Well yes, that's the point of this report. No-one has implemented a
> relocatable Emacs installation for general POSIX platforms. Solving
> those problems is part of it. A relocatable Emacs would not be installed
> as you describe above, it would (I imagine) be installed similar to the
> way the NS build is, under a single top-level directory.

The example above is still under a single top-level directory, called
'/usr' (a.k.a. ${prefix}).  Relocating just means changing ${prefix}
after Emacs was built.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.