Correct Paths to Emacs C Sources after Installation

Correct Paths to Emacs C Sources after Installation

[Alexander Shukaev]

Hello,

After building and installing Emacs, the C sources are not installed. How
to ask the build system for that?

Furthermore, if Emacs was built in some random (usually temporary) build
directory, then: when issuing Emacs documentation on some function which is
defined in C code and clicking the `C source code' link, Emacs would open
the corresponding C source file which is located in this random build
directory. This is definitely not something one would expect, especially in
the case when Emacs was built on a developer machine and distributed to
other users in a prebuilt form.

How to tell Emacs to recognize that the C sources are in say the "src"
directory which would be on the same level as the "bin" directory and
company (preferably in the relative form).

Thank you.

Regards,
Alexander

Re: Correct Paths to Emacs C Sources after Installation

[Eli Zaretskii]

> Date: Mon, 3 Nov 2014 21:55:05 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> 
> After building and installing Emacs, the C sources are not installed. How
> to ask the build system for that?

I think only manually.  Better yet, just unpack the sources in the
directory where you want them in the first place.

> Furthermore, if Emacs was built in some random (usually temporary) build
> directory, then: when issuing Emacs documentation on some function which is
> defined in C code and clicking the `C source code' link, Emacs would open
> the corresponding C source file which is located in this random build
> directory. This is definitely not something one would expect, especially in
> the case when Emacs was built on a developer machine and distributed to
> other users in a prebuilt form.
> 
> How to tell Emacs to recognize that the C sources are in say the "src"
> directory which would be on the same level as the "bin" directory and
> company (preferably in the relative form).

Try setting the variable source-directory.

Fwd: Correct Paths to Emacs C Sources after Installation

[Alexander Shukaev]

Wouldn't it be safer to patch:

  Vsource_directory
    = Fexpand_file_name (build_string ("../"),
 Fcar (decode_env_path (0, PATH_DUMPLOADSEARCH, 0)));

into something that will expand the path from the Emacs executable +
"../src/emacs" at run time? And possibly ask build system to copy sources
there.

Re: Correct Paths to Emacs C Sources after Installation

[Alexander Shukaev]

To put it all together, it seems to me that this could be a reasonable
change:

  Vsource_directory
    = Fexpand_file_name (build_string ("../src/emacs"),
Vinvocation_directory);

P.S. I don't know if "Vinvocation_directory" is already initialized at that
moment and can actually be used like that, but perhaps somebody could
clarify on that.

What do you think?

Regards,
Alexander

Re: Correct Paths to Emacs C Sources after Installation

[Stefan Monnier]

>   Vsource_directory
>     = Fexpand_file_name (build_string ("../src/emacs"),
>                          Vinvocation_directory);

Why would this particular default be useful?


        Stefan

Re: Correct Paths to Emacs C Sources after Installation

[Alexander Shukaev]

Once again. I want to play around with interactive documentation feature of
Emacs, i.e. clicking `C source code' links when searching for some
implementation details. That would be particularly cool for people who like
to hack on Emacs and actually, as I understand it, that's why such
interactive feature was introduced in the first place.

Two cases:

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

   Vsource_directory
       = Fexpand_file_name (build_string ("../"),
    Fcar (decode_env_path (0, PATH_DUMPLOADSEARCH, 0)));

   refers to a hard coded build directory path. Usually build directories
   are temporary and so after deleting it, one would not be able to browse C
   sources interactively. 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).
   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.

I thought these reasons were kind of obvious. What do you think of it?

Re: Correct Paths to Emacs C Sources after Installation

[John Mastro]

Alexander Shukaev <haroogan@gmail.com> wrote:
> Once again. I want to play around with interactive documentation feature of
> Emacs, i.e. clicking `C source code' links when searching for some
> implementation details. That would be particularly cool for people who like
> to hack on Emacs and actually, as I understand it, that's why such
> interactive feature was introduced in the first place.

I just put the following in my init file:

    (let ((source (format "~/src/emacs/emacs-%s/" emacs-version)))
      (when (file-directory-p source)
        (setq source-directory source)))

-- 
john

Re: Correct Paths to Emacs C Sources after Installation

[Alexander Shukaev]

>
> I just put the following in my init file:
>
>     (let ((source (format "~/src/emacs/emacs-%s/" emacs-version)))
>       (when (file-directory-p source)
>         (setq source-directory source)))
>

Of course, but this has to be done manually by end users to "clean-up"
wrong hard coded path. You can still do that if you want, but I believe
that the default has to be changed to something more reasonable. Since
there exist strict conventions on directory structure for open-source
software deployment ("bin", "src", "share", etc.), these have to be
exploited to install sources under ".../src/emacs" and referring to this
directory *relatively* from the currently running Emacs executable. To me
that looks like a robust and cross-platform default.

Re: Correct Paths to Emacs C Sources after Installation

[Alexis]

Alexander Shukaev writes:

>>
>> I just put the following in my init file:
>>
>>     (let ((source (format "~/src/emacs/emacs-%s/" emacs-version)))
>>       (when (file-directory-p source)
>>         (setq source-directory source)))
>>
>
> Of course, but this has to be done manually by end users to "clean-up"
> wrong hard coded path. You can still do that if you want, but I believe
> that the default has to be changed to something more reasonable. Since
> there exist strict conventions on directory structure for open-source
> software deployment ("bin", "src", "share", etc.), these have to be
> exploited to install sources under ".../src/emacs" and referring to this
> directory *relatively* from the currently running Emacs executable. To me
> that looks like a robust and cross-platform default.

i'm not sure i understand. i've built and installed 24.4 from
source. Say i do:

C-h f sort RET

A buffer is opened saying "sort is a built-in function in `C source
code'." If i TAB to the "C source code" link and press RET, the file
fns.c is opened in a new buffer, with point at line 1733:

DEFUN ("sort", Fsort, Ssort, 2, 2, 0,

i haven't done any particular configuration (e.g. something like the
above 'let')in order for all this to happen. It just works "out of the
box".

Is this in fact what you're wanting? If so, i take it the above doesn't
work for you?


Alexis.

Re: Correct Paths to Emacs C Sources after Installation

[Alexander Shukaev]

>
> Is this in fact what you're wanting? If so, i take it the above doesn't
> work for you?


Did you delete the build directory?

Re: Correct Paths to Emacs C Sources after Installation

[Alexander Shukaev]

Furthermore, I just don't get what exactly you don't understand. Do you
realize that the default `source-directory` is hard coded to the path where
Emacs sources were when you built them? You cannot relocate them now
without either manually changing the value of this variable through Emacs
Lisp or rebuilding Emacs from scratch so that the default changes. This
poses a major difficulty when distributing Emacs as a prebuilt package,
since on the developer machine sources would be located on some directory
which does not even exists for end users. How many more times should I
repeat that issue?

Re: Correct Paths to Emacs C Sources after Installation

[Alexander Shukaev]

Finally, look into documentation already:

source-directory is a variable defined in `lread.c'.
>


Documentation:
> Directory in which Emacs sources were found when Emacs was built.
> You cannot count on them to still be there!


Again:

You cannot count on them to still be there!


Do you understand now what is the problem?

Re: Correct Paths to Emacs C Sources after Installation

[Alexander Shukaev]

My proposal:

source-directory is a variable defined in `lread.c'.
>
> Documentation:
> Directory in which Emacs sources can be found.


and something like:

 Vsource_directory
>     = Fexpand_file_name (build_string ("../src/emacs"),
> Vinvocation_directory);


Additionally, an option to allow copying of source tree (that is being
built) to "${PREFIX}/src/emacs" has to be added to `configure`.

Re: Correct Paths to Emacs C Sources after Installation

[Alexis]

Alexander Shukaev writes:

> Did you delete the build directory?

No, i didn't. In contrast to yourself, i don't usually delete my build
directories, because i might need to rebuild with some slight
modifications; deleting everything would result in the entire build
being done from scratch, often (from my point of view) unnecessarily.

> Furthermore, I just don't get what exactly you don't understand. Do
> you realize that the default `source-directory` is hard coded to the
> path where Emacs sources were when you built them? You cannot relocate
> them now without either manually changing the value of this variable
> through Emacs Lisp or rebuilding Emacs from scratch so that the
> default changes. This poses a major difficulty when distributing Emacs
> as a prebuilt package, since on the developer machine sources would be
> located on some directory which does not even exists for end
> users. How many more times should I repeat that issue?

Well, my apologies; i got confused because, even though your original
post implied (to me) that the packaging issue was your primary concern,
in a subsequent post you mentioned both the packaging issue /and/ the
case where you yourself were compiling - but i then overlooked the fact
that you delete your build directories. Sorry!

i'm not one of the Emacs maintainers, myself, but i would think this is
something that needs to be decided by those who package Emacs. Not all
those packaging Emacs have end-users who want or need the C sources to
be available, so from the point of view of such packagers, including the
sources in the package would make it unnecessarily large. Furthermore,
different platforms (e.g. different Linux distros) might differ in where
such C sources should be located in their filesystem hierarchy
(e.g. they might have chosen /usr/src/ as the standard location for C
sources). So it seems to me it might be best for the Emacs build system
to not make decisions best left to package maintainers.


Alexis.

Re: Correct Paths to Emacs C Sources after Installation

[Alexander Shukaev]

>
> i'm not one of the Emacs maintainers, myself, but i would think this is
> something that needs to be decided by those who package Emacs. Not all
> those packaging Emacs have end-users who want or need the C sources to
> be available, so from the point of view of such packagers, including the
> sources in the package would make it unnecessarily large.


Packagers are not forced to include sources in this case. It's still
optional. Simply the default where to search for them becomes more
reasonable. Users can look it up in "source-directory" and put it there as
"src" on the same level as "bin" would be always available. Similarly those
who want to include sources, can do it without a obligating users to modify
"source-directory" manually in Emacs Lisp.

Furthermore,
> different platforms (e.g. different Linux distros) might differ in where
> such C sources should be located in their filesystem hierarchy
> (e.g. they might have chosen /usr/src/ as the standard location for C
> sources). So it seems to me it might be best for the Emacs build system
> to not make decisions best left to package maintainers.


"bin" should always have "src" near it. So whether one installs Emacs to
"/usr" or to "/usr/local" or wherever else, it would still be valid.

Re: Correct Paths to Emacs C Sources after Installation

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

() Alexander Shukaev <haroogan@gmail.com>
() Tue, 4 Nov 2014 01:35:51 +0100

   there exist strict conventions

Hmm, that sounds like an oxymoron to my ears...

If you want to copy the C files on "make install" to DIR (a
laudable initiative, you are to be commended!), i suggest you:

- grok configure.ac
- add there support for option ‘--install-C-source DIR’
  (with default not to install)
- arrange to tweak ‘source-directory’ on "make install"
- test a few times
  - in "strict convention" contexts
  - outside "strict convention" contexts
    (use your imagination, or ask around;
    weird and wonderful people abound!)
- post a patch for review
- bask in the glow once the revised^N patch is installed
- mention this (v.cool, IMHO) feature on EmacsWiki

Lastly, you can (optionally) prepare for the onslaught of
"next step" bug reports, wherein users stumble upon the
feature and wonder how to make a modification to the code
and see the effect immediately in action.  That sweet
confusion is something we can address together, here.  :-D

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Correct Paths to Emacs C Sources after Installation

[Eli Zaretskii]

> Date: Tue, 4 Nov 2014 01:35:51 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> 
> >
> > I just put the following in my init file:
> >
> >     (let ((source (format "~/src/emacs/emacs-%s/" emacs-version)))
> >       (when (file-directory-p source)
> >         (setq source-directory source)))
> >
> 
> Of course, but this has to be done manually by end users to "clean-up"
> wrong hard coded path.

You can provide your users with a site-init file that will do it for
them.

Moreover, if source-directory points to a non-existing place, Emacs
will prompt (once) for the source directory.

> Since there exist strict conventions on directory structure for
> open-source software deployment ("bin", "src", "share", etc.)

Where did you find conventions about the "src" trees?  Can you provide
a link to those conventions?  I'm not aware of such conventions.

> these have to be exploited to install sources under ".../src/emacs"

This is wrong: it doesn't include the version number, so it will be
overwritten by each new installation.

> To me that looks like a robust and cross-platform default.

Defaults only make sense if they are widely used.  This one isn't.

Re: Correct Paths to Emacs C Sources after Installation

[Stefan Monnier]

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

I haven't paid attention, so maybe it is a wide-spread convention, but
although I can't deny your claim, I do need some convincing.

Can you give "typical examples" where (expand-file-name "../src/emacs"
invocation-directory) will give the right result?

>    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"?

This is done under the assumption that a common case is when Emacs was
built locally.  And I think it's more common for Emacs to be built
locally, compared to the situation where the user installed
a precompiled package and then fetched the sources.


        Stefan

Re: Correct Paths to Emacs C Sources after Installation

[Alexander Shukaev]

>
> This is done under the assumption that a common case is when Emacs was
> built locally.  And I think it's more common for Emacs to be built
> locally, compared to the situation where the user installed
> a precompiled package and then fetched the sources.


I happen to disagree, I'd say 99% of Emacs users have no clue how to build
it. Many (probably most?) Linux distributions serve prebuilt packages.
MSYS2 on Windows serve prebuilt packages through pacman (package manager
ported from Arch Linux) as well. Cygwin serves prebuilt packages. I provide
standalone Emacs builds for Windows too. Furthermore, Eli told me recently
that sources should be included (either separately or in the same archive)
anyway to be compliant with the license.

Can you give "typical examples" where (expand-file-name "../src/emacs"
> invocation-directory) will give the right result?


Would you agree that this is *at least* more reasonable default in many
cases than hard coding nonexistent directory? There were plenty of examples
like relocating/deleting sources from original location where they were
during build or moving to different machine with prebuilt Emacs (for
instance on UFD) or distributing it as prebuilt package to other users. I
don't know what other "more" convincing examples you want to find as these
ones pretty much cover the use cases of "source-directory" variable.

Last but not least, in many package managers there are options to install
sources separately from binaries and by convention they are usually
installed under corresponding "src/<package-name>" suffix. This again
proves that my proposed default is more reasonable than a hard coded path
to some random directory.

Re: Correct Paths to Emacs C Sources after Installation

[Eli Zaretskii]

> Date: Tue, 4 Nov 2014 16:33:54 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> 
> Furthermore, Eli told me recently that sources should be included
> (either separately or in the same archive) anyway to be compliant
> with the license.

I meant a separate source archive, of course.  That had nothing to do
with having the sources installed, let alone in some specific public
place.

> Can you give "typical examples" where (expand-file-name "../src/emacs"
> > invocation-directory) will give the right result?
> 
> 
> Would you agree that this is *at least* more reasonable default in many
> cases than hard coding nonexistent directory?

No, it's much *less* reasonable.

> There were plenty of examples like relocating/deleting sources from
> original location where they were during build or moving to
> different machine with prebuilt Emacs (for instance on UFD) or
> distributing it as prebuilt package to other users. I don't know
> what other "more" convincing examples you want to find as these ones
> pretty much cover the use cases of "source-directory" variable.

Relocating things will not necessarily put them in ../src/ relative to
the binaries.  There's any number of other places, so the probability
of winding up in ../src is close to zero.

Re: Correct Paths to Emacs C Sources after Installation

[Alexander Shukaev]

OK, let's forget about installing sources with Autotools, that was just an
optional feature that I thought of, but that is not an important point here.

Many package managers have options to install sources separately from
binaries and by convention they are usually installed under corresponding
"src/<package-name>" suffix. This is what makes my proposal reasonable.
Otherwise users end up with hard coded path to random directory from a
build machine. Is that what you consider a reasonable default for the
majority?

Re: Correct Paths to Emacs C Sources after Installation

[Alexander Shukaev]

>
> Where did you find conventions about the "src" trees?  Can you provide
> a link to those conventions?  I'm not aware of such conventions.


I don't know what is your OS, but if you are on Linux or something alike,
then you could check the contents of your "/usr/local/src" directory. You
could also take a look at Filesystem Hierarchy Standard
<http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY>.

Re: Correct Paths to Emacs C Sources after Installation

[Eli Zaretskii]

> Date: Tue, 4 Nov 2014 17:18:41 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> 
>     Where did you find conventions about the "src" trees? Can you provide
>     a link to those conventions? I'm not aware of such conventions.
> 
> I don't know what is your OS, but if you are on Linux or something alike, then
> you could check the contents of your "/usr/local/src" directory. You could also
> take a look at Filesystem Hierarchy Standard.

Thanks.  But the fact is, no GNU project I know of has rules in its
Makefiles to install sources, to /usr/local/src or anywhere else.

Re: Correct Paths to Emacs C Sources after Installation

[Eli Zaretskii]

> Date: Tue, 4 Nov 2014 17:07:42 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> 
> Many package managers have options to install sources separately from binaries
> and by convention they are usually installed under corresponding
> "src/<package-name>" suffix. This is what makes my proposal reasonable.
> Otherwise users end up with hard coded path to random directory from a build
> machine. Is that what you consider a reasonable default for the majority?

You'd need to show actual patches to do you want, for this discussion
to be constructive.  (And btw, this is not the place to discuss such
patches.)

Emacs includes some logic to detect whether it is run uninstalled
(i.e. from the src or build directory) or after installation.
Whatever changes you propose should not break that logic, and should
continue to support the current setup, where Emacs is built in some
place not even close to its binary, then installed under /usr/, and
the sources are left where it was built.  If your changes satisfy
these requirements, they will be considered, I think (but no promises,
as I have no idea what other people on emacs-devel will say).

Re: Correct Paths to Emacs C Sources after Installation

[Stefan Monnier]

> Many package managers have options to install sources separately from
> binaries and by convention they are usually installed under corresponding
> "src/<package-name>" suffix.

I understand that this is your motivation, but could you make it
more concrete?  E.g. give at least one package manager which does that
(giving the actual commands which lead to the source being placed there)
and uses "emacs" for <package-name>.


        Stefan

Re: Correct Paths to Emacs C Sources after Installation

[Alexander Shukaev]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

>
> I understand that this is your motivation, but could you make it
> more concrete?  E.g. give at least one package manager which does that
> (giving the actual commands which lead to the source being placed there)
> and uses "emacs" for <package-name>.


I will give you the simplest visual example possible: Cygwin (see the
attachment). Sources will end up under "/usr/local/src/emacs".

Thanks.  But the fact is, no GNU project I know of has rules in its
> Makefiles to install sources, to /usr/local/src or anywhere else.


It however turns out that you still already follow the convention by
default. The current default directory structure of Emacs installation is:

bin
libexec
share
var

Is this by accident? I'm quite sure that it is not. Adding "src/emacs" and
supporting it by default is just the right thing to do.

Anyway, I will prepare a patch for consideration soon.

[-- Attachment #2: cygwin.PNG --]
[-- Type: image/png, Size: 40795 bytes --]

Re: Correct Paths to Emacs C Sources after Installation

[Glenn Morris]

Alexander Shukaev wrote:

> Adding "src/emacs" and supporting it by default is just the right
> thing to do.

I really don't think it is. The only thing I have ever seen use /usr/src
on GNU/Linux machines is the Linux kernel and other related items where
the sources are needed for compiling kernel modules.

I have never seen a single program install its sources there for
information purposes only, which is what this would be. So I would not
like Emacs to accept a patch to do that.

IMO the only possible location for an optional `install-source' target
to install to is share/emacs/VERSION/src. I don't expect any pre-built
binary package of Emacs to ever use such a feature, but I would not have
a problem with such a patch.

Re: Correct Paths to Emacs C Sources after Installation

[Alexander Shukaev]

>
> I really don't think it is. The only thing I have ever seen use /usr/src
> on GNU/Linux machines is the Linux kernel and other related items where
> the sources are needed for compiling kernel modules.
>

Perhaps you should look into "/usr/local/src". This is the place where
package managers can fetch the so-called "source packages", those which
contain only the source code.

IMO the only possible location for an optional `install-source' target
> to install to is share/emacs/VERSION/src. I don't expect any pre-built
> binary package of Emacs to ever use such a feature, but I would not have
> a problem with such a patch.
>

This is also a good idea that I thought about myself. For browsing purposes
only, this is a good place to store sources. Shall we move to emacs-devel
now for further discussion?

Re: Correct Paths to Emacs C Sources after Installation

[Bob Proulx]

Alexander Shukaev wrote:
> > I really don't think it is. The only thing I have ever seen use /usr/src
> > on GNU/Linux machines is the Linux kernel and other related items where
> > the sources are needed for compiling kernel modules.
> 
> Perhaps you should look into "/usr/local/src". This is the place where
> package managers can fetch the so-called "source packages", those which
> contain only the source code.

The /usr/local tree won't be used directly by package managers.
Talking dpkg and rpm specifically here.  The /usr/local tree is for
the local admin to do with as they will.  (PATH variables such as
Perl's INC and others may include /usr/local paths so that packaged
tools integrate into the packaged tools installed into system
directories.)  If you want it installed by a package manager then the
/usr/share/emacs/VERSION directory is about the only acceptable place
for it.

Personally I always felt that if you want to look at the source code
then it makes the most sense to download source and compile it.  In
which case source will be wherever you have placed it.  In my case
that is in my ~/src/foo directory tree.  Being my own copy it means I
can make modifications and compile those modifications.  Having
modified it means that I want it in version control so that I can use
it for diff'ing, for branching, generating patches, and general source
control.

Bob

Re: Correct Paths to Emacs C Sources after Installation

[Yuri Khan]

On Wed, Nov 5, 2014 at 1:20 AM, Alexander Shukaev <haroogan@gmail.com> wrote:

> Perhaps you should look into "/usr/local/src". This is the place where
> package managers can fetch the so-called "source packages", those which
> contain only the source code.

Nonsense. The /usr/local tree is, by definition, off-limits for
package managers.

http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLOCALLOCALHIERARCHY

Re: Correct Paths to Emacs C Sources after Installation

[Ted Zlatanov]

On Wed, 5 Nov 2014 09:43:04 +0700 Yuri Khan <yuri.v.khan@gmail.com> wrote: 

YK> On Wed, Nov 5, 2014 at 1:20 AM, Alexander Shukaev <haroogan@gmail.com> wrote:
>> Perhaps you should look into "/usr/local/src". This is the place where
>> package managers can fetch the so-called "source packages", those which
>> contain only the source code.

YK> Nonsense. The /usr/local tree is, by definition, off-limits for
YK> package managers.

YK> http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLOCALLOCALHIERARCHY

Homebrew on Mac OS X happily uses /usr/local. In particular I can find
the sources of any package I build in /usr/local/Cellar, which has been
convenient several times for non-Emacs purposes (with Emacs, as a
developer, I check it out to a local directory so I don't use its
Homebrew source directory much). I hope that helps.

Ted

Re: Correct Paths to Emacs C Sources after Installation

[Stefan Monnier]

> I will give you the simplest visual example possible: Cygwin (see the
> attachment). Sources will end up under "/usr/local/src/emacs".

Thanks.  So maybe it makes sense to do that for the Cygwin build (tho,
still only after checking that the original value of source-directory
points to a non-existing directory).


        Stefan

Re: Correct Paths to Emacs C Sources after Installation

[Jason Rumney]

On Wednesday, 5 November 2014 10:07:36 UTC+8, Stefan Monnier  wrote:

> > I will give you the simplest visual example possible: Cygwin (see the
> > attachment). Sources will end up under "/usr/local/src/emacs".
> 
> Thanks.  So maybe it makes sense to do that for the Cygwin build (tho,
> still only after checking that the original value of source-directory
> points to a non-existing directory).

Or the package maintainers could build from the location where their packaged sources are intended to be installed, then the current source-directory would be correct without messing things up for Cygwin users who pull from git, and build from their HOME directory or elsewhere.

Re: Correct Paths to Emacs C Sources after Installation

[Stefan Monnier]

> I happen to disagree, I'd say 99% of Emacs users have no clue how to build
> it.  Many (probably most?) Linux distributions serve prebuilt packages.
> MSYS2 on Windows serve prebuilt packages through pacman (package manager
> ported from Arch Linux) as well.  Cygwin serves prebuilt packages.  I provide
> standalone Emacs builds for Windows too.  Furthermore, Eli told me recently
> that sources should be included (either separately or in the same archive)
> anyway to be compliant with the license.

The only relevant comparison is "built locally" with "the user installed
a precompiled package and then fetched the sources".  So users who don't
have the source are not relevant.

>> Can you give "typical examples" where (expand-file-name "../src/emacs"
>> invocation-directory) will give the right result?
> Would you agree that this is *at least* more reasonable default in many
> cases than hard coding nonexistent directory?

*If* the current value points to an non-existing directory and if
../src/emacs points to an existing directory, then yes, it's probably
a better default.  The question is whether it'd happen often enough to
justify the corresponding code.

> Last but not least, in many package managers there are options to install
> sources separately from binaries and by convention they are usually
> installed under corresponding "src/<package-name>" suffix. This again
> proves that my proposed default is more reasonable than a hard coded path
> to some random directory.

I'm not debating whether it's reasonable or not.  I never said it was
not reasonable.  I just would like to see some concrete examples where
"../src/emacs" would work.

I do think it's important to make it easier to jump to the sources
(which is why I wrote the code that adds the "C source" button).
Another approach is to leave the default value of source-directory alone
and instead change the behavior of the "C source" button so that (if
source-directory doesn't exist) it tries a bunch of alternative
directories.  Yet another option is to offer to actually download the
code (or visit it straight from the Git repository via the URL package).
Prebuilt packages (such as Debian's) could tweak the code to offer to
install the corresponding source package.


        Stefan


PS: Side note: the right way to propose such a change is to submit it
via M-x report-emacs-bug.

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.

Re: Fwd: Correct Paths to Emacs C Sources after Installation

[Eli Zaretskii]

> Date: Mon, 3 Nov 2014 22:31:15 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> 
> Wouldn't it be safer to patch:
>
>   Vsource_directory
>     = Fexpand_file_name (build_string ("../"),
>  Fcar (decode_env_path (0, PATH_DUMPLOADSEARCH, 0)));
>
> into something that will expand the path from the Emacs executable +
> "../src/emacs" at run time?

You mean, by default?  No, because such a default will never be
correct, except (evidently) in your very special use case.

Moreover, the resulting directory will not be version-specific, so it
is wrong even in your case, because the next installation will
overwrite the source tree, and older Emacs binaries will not find
their matching sources.

> And possibly ask build system to copy sources there.

No other project installs sources, so this would be unusual.