Links emacs -> emacs-NN.MM.KK

Links emacs -> emacs-NN.MM.KK

[Eli Zaretskii]

Why do we create a hard link emacs -> emacs.NN.MM.KK when dumping in
the src directory, but a symbolic link in "make install"?  Why the
difference?

Re: Links emacs -> emacs-NN.MM.KK

[Glenn Morris]

Eli Zaretskii wrote:

> Why do we create a hard link emacs -> emacs.NN.MM.KK when dumping in
> the src directory, but a symbolic link in "make install"?  Why the
> difference?

We use a symlink when installing if configure says they are supported.
It just seems like the right thing to do in that case (makes it more
obvious what is going on, people in the past have been confused about
why bin/emacs was getting "installed twice", etc).

It's a relatively recent change to do so rather than use a hard link.
Either I forgot to consider src/Makefile at that time, or decided it
wasn't worth bothering to change that part, or decided there was some
reason not to. Such a reason would be if we delete one end of the link
and still expect the other to work. I'm afraid I don't remember which of
these explanations applies, sorry.

Re: Links emacs -> emacs-NN.MM.KK

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 06 Apr 2013 15:42:50 -0400
> 
> Eli Zaretskii wrote:
> 
> > Why do we create a hard link emacs -> emacs.NN.MM.KK when dumping in
> > the src directory, but a symbolic link in "make install"?  Why the
> > difference?
> 
> We use a symlink when installing if configure says they are supported.
> It just seems like the right thing to do in that case (makes it more
> obvious what is going on, people in the past have been confused about
> why bin/emacs was getting "installed twice", etc).
> 
> It's a relatively recent change to do so rather than use a hard link.
> Either I forgot to consider src/Makefile at that time, or decided it
> wasn't worth bothering to change that part, or decided there was some
> reason not to.

It's not in src/Makefile, it's in loadup.el, whicvh uses
add-name-to-file.

> Such a reason would be if we delete one end of the link and still
> expect the other to work. I'm afraid I don't remember which of these
> explanations applies, sorry.

OK, thanks.  So it shouldn't be a problem if the Windows build uses a
hard link in this case, I think, or a copy if the filesystem is FAT32
that doesn't support hard links.  Creating symlinks is a PITA on
Windows, as they require privileges and pop up UAC prompts.