On Wed, Oct 25, 2023 at 2:32 PM Eli Zaretskii <
eliz@gnu.org> wrote:
> From: chad <yandros@gmail.com>
> Date: Wed, 25 Oct 2023 13:43:01 -0400
> Cc: emacs-devel@gnu.org
>
> I don't run under macOS any more, but when I did, there was an extra wrinkle here: emacs typically
> builds as an "app bundle", essentially a directory named "Emacs.app" that contains all of the stuff
> that a typical unix-like installation would put in various subdirs of /usr/local. This was actually quite
> nice -- it meant that I could have a complete, functional version of emacs in both Emacs.app and
> Emacs-old.app whenever I wanted to try something new without stranding myself if the new thing
> turned out to be broken.
??? The "Unix-like" installation puts these files in version-specific
directories, so you can have several Emacs versions available on the
same system at the same time. I do that all the time, and have about
a dozen Emacs versions installed and runnable.
This works if the versions have distinct version numbers, which was not
always the case in my experience back then. This was especially relevant
when testing alternative ports, such as ns versus carbon, different toolkits,
and when hunting bugs or testing features that required a longer run-time
to exercise. This Emacs.app approach applied to building from HEAD as
well (my primary use case for many years).
The key thing I was trying to convey is just this: a commonly used platform
keeps all of these relevant files in a non-shared, non-central, non-source-tree
hierarchy, then arranges on startup to find these directories and set appropriate
elisp vars to DTRT. If one wants to change the process of finding sources in
emacs, and one wants to support macOS, one should expect a little extra
effort needed on that platform.
~Chad