emacs-app: hardcoded build path

[mojca (Mojca Miklavec)]

When compiling gnuplot I run across the problem that I can reproduce as follows. Take a file dot.el with the following contents:

(setq load-path             (append (list ".") load-path)
      byte-compile-verbose  nil
      byte-compile-warnings nil)
(require 'font-lock)
(defun hilit-repaint-command (foo))

and execute the following:

ln -s /Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs /tmp/myemacs
/tmp/myemacs -batch -q -no-site-file -l dot.el

On my computer this fails with:

Warning: arch-dependent data dir (/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_emacs-app/emacs-app/work/emacs-24.2/nextstep/Emacs.app/Contents/MacOS//libexec/emacs/24.2/x86_64-apple-darwin11.4.0/) does not exist.
Warning: arch-independent data dir (/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_emacs-app/emacs-app/work/emacs-24.2/nextstep/Emacs.app/Contents/Resources/share/emacs/24.2/etc/) does not exist.
Error: charsets directory not found:
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_emacs-app/emacs-app/work/emacs-24.2/nextstep/Emacs.app/Contents/Resources/share/emacs/24.2/etc/charsets
Emacs will not function correctly without the character map files.
Please check your installation!

When linking against /opt/local/bin/emacs I don't have that problem.

[jrhope]

A simplified test (it's not specific to the .el file):

$ ln -s /Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs /tmp/emacs
$ /tmp/emacs
Warning: arch-dependent data dir (/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_emacs-app/emacs-app/work/emacs-24.2/nextstep/Emacs.app/Contents/MacOS//libexec/emacs/24.2/x86_64-apple-darwin12.2.0/) does not exist.
Warning: arch-independent data dir (/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_emacs-app/emacs-app/work/emacs-24.2/nextstep/Emacs.app/Contents/Resources/share/emacs/24.2/etc/) does not exist.
Error: charsets directory not found:
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_emacs-app/emacs-app/work/emacs-24.2/nextstep/Emacs.app/Contents/Resources/share/emacs/24.2/etc/charsets
Emacs will not function correctly without the character map files.
Please check your installation!

[humem (humem)]

Emacs.app is relocatable while /opt/local/bin/emacs is not, and you should not separate the Emacs binary from other data files, because the binary could not find them based on the relative paths. How about linking the whole app and invoking the binary? I mean:

$ ln -s /Applications/MacPorts/Emacs.app /tmp/e
$ /tmp/e/Contents/MacOS/Emacs

[jrhope]

Replying to hum@…:

Emacs.app is relocatable while /opt/local/bin/emacs is not, and you should not separate the Emacs binary from other data files, because the binary could not find them based on the relative paths.

OK, so you're saying that Emacs.app is set up to search within its (relocatable) app bundle, and so the symlink fails because it's looking for stuff at `dirname argv[0]`/libexec/ and `dirname argv[0]`/../Resources/ (pardon the syntax abuse). That makes sense, and I suppose it means this bug is really a feature.

The confusing part to me, though, is that the error messages look like

Warning: arch-dependent data dir (/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_emacs-app/emacs-app/work/emacs-24.2/nextstep/Emacs.app/Contents/MacOS//libexec/emacs/24.2/x86_64-apple-darwin12.2.0/) does not exist.
Warning: arch-independent data dir (/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_emacs-app/emacs-app/work/emacs-24.2/nextstep/Emacs.app/Contents/Resources/share/emacs/24.2/etc/) does not exist.
Error: charsets directory not found:
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_emacs-app/emacs-app/work/emacs-24.2/nextstep/Emacs.app/Contents/Resources/share/emacs/24.2/etc/charsets

and not

Warning: arch-dependent data dir (./libexec/emacs/24.2/x86_64-apple-darwin12.2.0/) does not exist.
Warning: arch-independent data dir (../Contents/Resources/share/emacs/24.2/etc/) does not exist.
Error: charsets directory not found:
../Resources/share/emacs/24.2/etc/charsets

[mojca (Mojca Miklavec)]

Replying to jrh@…:

Replying to hum@…:

Emacs.app is relocatable while /opt/local/bin/emacs is not, and you should not separate the Emacs binary from other data files, because the binary could not find them based on the relative paths.

OK, so you're saying that Emacs.app is set up to search within its (relocatable) app bundle, and so the symlink fails because it's looking for stuff at `dirname argv[0]`/libexec/ and `dirname argv[0]`/../Resources/ (pardon the syntax abuse). That makes sense, and I suppose it means this bug is really a feature.

TeX is also relocatable and uses SELFAUTOPARENT (../) to find texmf.cnf, but one can use an arbitrary number of symlinks. It just works - the files are searched relative from the executable not relative to the symlinks. So even if that's the case it is still very suboptimal behaviour. And I don't like the fact that it complains about files missing in the original building directory

[mwette]

If you check emacs-dist/src/charset.c you will see why it picks up the installation directories. Oddly, the data-directory variable in my running emacs seems fine. If you run into this problem from the command line, try setting the environment variable EMACSDATA to the /Application/.../etc directory.