Re: Correct Paths to Emacs C Sources after Installation

[Eli Zaretskii]

> Date: Tue, 4 Nov 2014 00:05:47 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> 
>    1. I build and install Emacs for personal usage. Does not even matter on
>    what platform Unix-like or Windows. Sources are not installed by default,
>    but I believe their either should or at least an option has to be provided
>    for that.

No other project does that, so Emacs is not an exception here, but
rather the rule.  It is OK to do that in your special case, of course,
but you are lobbying for the project to cater to such a special use
case, which I personally am not convinced is justified.  See below.

>    Usually build directories are temporary and so after deleting it,
>    one would not be able to browse C sources interactively.

"Usually", users don't need to browse the sources to understand what
the function/variable does and how to use it.  The only reasons for
this information not to be found in the doc string itself are:
(a) documentation bugs, for which you are kindly requested to file bug
reports; and (b) aspects the developers deliberately decided not to
document because they are internal details that are not supposed to be
exposed to Lisp, and are frequently subject to change without notice.

I understand that you have some project in mind where you would like
the C source-level code be available, but that is a very special use
case.

>    Furthermore, it is conceptually "stupid" to separate
>    sources from built Emacs when, in fact, this built Emacs wants to refer to
>    these sources it was built from. I think nobody can deny that it's pretty
>    much a convention to distribute open-source project sources under
>    ".../src/name" (for potential further usage or reference like we have in
>    this case as well).

You are mixing 2 unrelated issues: (1) the legal requirement of the
GPL to provide users with sources that were used to build a
distributed binary, and (2) whether or not to have those sources
installed on the end-user machines.  The former requirement is
satisfied by having a source tarball near the binary one; then users
who want to study or modify the Emacs sources can unpack the sources
and point source-directory to where they unpack it.  The latter
requirement doesn't exist in most cases, it is something you need for
your specific project.

>    2. I build and install Emacs, then I package it and distribute to end
>    users. Why on Earth should the path to the build directory (which obviously
>    does not exist on end users' machines) that I used be hard coded into
>    "Vsource_directory"? And again this leads us to the same argument as in #1.

You can provide a site-init file with that distribution that redirects
source-directory to where the sources will be after installing the
distribution.

Once again: the defaults are for the majority.  Situations that don't
fit the "usual" use cases are handled by customizing Emacs.  I submit
that Emacs allows you to customize it even for your unusual use case.