emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: source-directory, installed Emacs, and C source


From: Eli Zaretskii
Subject: Re: source-directory, installed Emacs, and C source
Date: Thu, 26 Oct 2023 07:57:51 +0300

> From: chad <yandros@gmail.com>
> Date: Wed, 25 Oct 2023 16:30:01 -0400
> Cc: sbaugh@catern.com, emacs-devel@gnu.org
> 
>  ??? 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.

Changing the version of Emacs for your local purposes is a very simple
procedure, a matter of running a Lisp function in admin.el and then
rebuilding.  If you need to have multiple XX.YY versions of Emacs
installed with the same XX.YY, just set the version to be XX.YY.zz,
with zz chosen by you, and then rebuild and install.  It's very simple.

> 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.

Files produced by the build that are architecture-dependent are
installed in architecture-specific subdirectories or /usr/local, so
you can have several Emacs versions on the same machine compiled for
different architectures, let alone different configurations.

> 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.

I don't think we need to learn anything from macOS in this area.  Our
current installation system solves these issues in a different manner,
but it does solve them, and the solutions are simple, easy to
understand, and easy to use (unlike macOS solutions that are so
obscure and complex that even macOS users here don't really understand
all their quirks).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]