Installing the Emacs executable

Installing the Emacs executable

[Eli Zaretskii]

"make install" installs 2 executables: 'emacs-24.3.50' and 'emacs'
that is a symlink to 'emacs-24.3.50'.  It also installs
DOC-24.3.50.nn, where nn is the serial number of the build of this
version of Emacs in the build tree.

The next time you build and "make install", you get the same
'emacs-24.3.50' (which is a different executable) and DOC-24.3.50.nn+1
as its DOC file.  The previous DOC-24.3.50.nn is deleted.

Is this done on purpose?  Why isn't the binary named the same as its
DOC, i.e. emacs-24.3.50.nn?

Re: Installing the Emacs executable

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Is this done on purpose?  Why isn't the binary named the same as its
> DOC, i.e. emacs-24.3.50.nn?

I'd rather see the build number removed at all.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Installing the Emacs executable

[Glenn Morris]

Andreas Schwab wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Is this done on purpose?  Why isn't the binary named the same as its
>> DOC, i.e. emacs-24.3.50.nn?
>
> I'd rather see the build number removed at all.

I agree with you (IIUC what you are saying); I've never found it useful.
(IIRC rms is/was a fan of it.)

Re: Installing the Emacs executable

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Tue, 16 Apr 2013 13:20:33 -0400
> 
> Andreas Schwab wrote:
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >> Is this done on purpose?  Why isn't the binary named the same as its
> >> DOC, i.e. emacs-24.3.50.nn?
> >
> > I'd rather see the build number removed at all.
> 
> I agree with you (IIUC what you are saying); I've never found it useful.
> (IIRC rms is/was a fan of it.)

It could make sense if we kept the old builds, like we do in the build
tree.

Anyway, I understand that I didn't miss anything; if/when this is
fixed on Posix platforms, the Posix-style Windows build will get the
same automagically.

Thanks.

Re: Installing the Emacs executable

[Andreas Schwab]

Glenn Morris <rgm@gnu.org> writes:

> Andreas Schwab wrote:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> Is this done on purpose?  Why isn't the binary named the same as its
>>> DOC, i.e. emacs-24.3.50.nn?
>>
>> I'd rather see the build number removed at all.
>
> I agree with you (IIUC what you are saying); I've never found it useful.
> (IIRC rms is/was a fan of it.)

Like this:

	* loadup.el: Don't append build number to emacs-version.
---
 lisp/loadup.el | 18 ------------------
 1 file changed, 18 deletions(-)

diff --git a/lisp/loadup.el b/lisp/loadup.el
index 00c5234..097dd02 100644
--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -284,24 +284,6 @@
 ;For other systems, you must edit ../src/Makefile.in.
 (load "site-load" t)
 
-;; Determine which last version number to use
-;; based on the executables that now exist.
-(if (and (or (equal (nth 3 command-line-args) "dump")
-	     (equal (nth 4 command-line-args) "dump"))
-	 (not (eq system-type 'ms-dos)))
-    (let* ((base (concat "emacs-" emacs-version "."))
-	   (files (file-name-all-completions base default-directory))
-	   (versions (mapcar (function (lambda (name)
-					 (string-to-number (substring name (length base)))))
-			     files)))
-      (setq emacs-bzr-version (condition-case nil (emacs-bzr-get-version)
-                              (error nil)))
-      ;; `emacs-version' is a constant, so we shouldn't change it with `setq'.
-      (defconst emacs-version
-	(format "%s.%d"
-		emacs-version (if versions (1+ (apply 'max versions)) 1)))))
-
-
 (message "Finding pointers to doc strings...")
 (if (or (equal (nth 3 command-line-args) "dump")
 	(equal (nth 4 command-line-args) "dump"))
-- 
1.8.2.1


Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Installing the Emacs executable

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Fri, 19 Apr 2013 20:29:53 +0200
> 
> Glenn Morris <rgm@gnu.org> writes:
> 
> > Andreas Schwab wrote:
> >
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >>> Is this done on purpose?  Why isn't the binary named the same as its
> >>> DOC, i.e. emacs-24.3.50.nn?
> >>
> >> I'd rather see the build number removed at all.
> >
> > I agree with you (IIUC what you are saying); I've never found it useful.
> > (IIRC rms is/was a fan of it.)
> 
> Like this:
> 
> 	* loadup.el: Don't append build number to emacs-version.

This will overwrite the previous Emacs binary in src as well (and its
DOC in etc), won't it?  Do we really want to toss the possibility of
being able to easily run previous builds of the same version?

Re: Installing the Emacs executable

[Glenn Morris]

Eli Zaretskii wrote:

> This will overwrite the previous Emacs binary in src as well (and its
> DOC in etc), won't it?  Do we really want to toss the possibility of
> being able to easily run previous builds of the same version?

Well yes, that is basically the motivation for the build number
existing, as I understand it. As I said, I have personally never found
this a useful feature. Does any other project do this?
Maybe it could be a configure option (probably madness). :)

Re: Installing the Emacs executable

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Andreas Schwab <schwab@linux-m68k.org>,  emacs-devel@gnu.org
> Date: Fri, 19 Apr 2013 14:57:12 -0400
> 
> Eli Zaretskii wrote:
> 
> > This will overwrite the previous Emacs binary in src as well (and its
> > DOC in etc), won't it?  Do we really want to toss the possibility of
> > being able to easily run previous builds of the same version?
> 
> Well yes, that is basically the motivation for the build number
> existing, as I understand it. As I said, I have personally never found
> this a useful feature. Does any other project do this?

That's a different issue.  My question was about what "make install"
does with DOC, not what "make emacs" does in src.  We can install DOC
under the name DOC-XX.YY.ZZ without changing what happens in src and
in etc of the build tree.

Re: Installing the Emacs executable

[Glenn Morris]

Eli Zaretskii wrote:

> That's a different issue.  My question was about what "make install"
> does with DOC, not what "make emacs" does in src.  We can install DOC
> under the name DOC-XX.YY.ZZ without changing what happens in src and
> in etc of the build tree.

Oh, I missed that. FWIW, I have never found the .ZZ part useful whether
installed or uninstalled.

Re: Installing the Emacs executable

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> My question was about what "make install" does with DOC,

??? Nothing, as before.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Installing the Emacs executable

[Stefan Monnier]

>> That's a different issue.  My question was about what "make install"
>> does with DOC, not what "make emacs" does in src.  We can install DOC
>> under the name DOC-XX.YY.ZZ without changing what happens in src and
>> in etc of the build tree.
> Oh, I missed that. FWIW, I have never found the .ZZ part useful whether
> installed or uninstalled.

FWIW, my local hacks get rid of "DOC-NN.MM" in favor of "DOC" and my
local "make" script does "rm src/emacs-[0-9]*" before running make.


        Stefan

Re: Installing the Emacs executable

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Glenn Morris <rgm@gnu.org>,  emacs-devel@gnu.org
> Date: Fri, 19 Apr 2013 22:58:16 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > My question was about what "make install" does with DOC,
> 
> ??? Nothing, as before.

Which is exactly the problem.  I think it should do the same as what
it does with $(EMACS) and $(EMACSFULL).

Re: Installing the Emacs executable

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> I think it should do the same as what it does with $(EMACS) and
> $(EMACSFULL).

Why?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Installing the Emacs executable

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: rgm@gnu.org,  emacs-devel@gnu.org
> Date: Sat, 20 Apr 2013 12:44:13 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think it should do the same as what it does with $(EMACS) and
> > $(EMACSFULL).
> 
> Why?

For consistency.

Re: Installing the Emacs executable

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: rgm@gnu.org,  emacs-devel@gnu.org
>> Date: Sat, 20 Apr 2013 12:44:13 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > I think it should do the same as what it does with $(EMACS) and
>> > $(EMACSFULL).
>> 
>> Why?
>
> For consistency.

??? What consistency?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Installing the Emacs executable

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: rgm@gnu.org,  emacs-devel@gnu.org
> Date: Sat, 20 Apr 2013 13:55:10 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andreas Schwab <schwab@linux-m68k.org>
> >> Cc: rgm@gnu.org,  emacs-devel@gnu.org
> >> Date: Sat, 20 Apr 2013 12:44:13 +0200
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> > I think it should do the same as what it does with $(EMACS) and
> >> > $(EMACSFULL).
> >> 
> >> Why?
> >
> > For consistency.
> 
> ??? What consistency?

"Consistency" as in "do the same as".

Re: Installing the Emacs executable

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> "Consistency" as in "do the same as".

Doing what?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Installing the Emacs executable

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: rgm@gnu.org,  emacs-devel@gnu.org
> Date: Sat, 20 Apr 2013 15:24:45 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > "Consistency" as in "do the same as".
> 
> Doing what?

What I described.

Re: Installing the Emacs executable

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: rgm@gnu.org,  emacs-devel@gnu.org
>> Date: Sat, 20 Apr 2013 15:24:45 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > "Consistency" as in "do the same as".
>> 
>> Doing what?
>
> What I described.

No, you have failed so far.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Installing the Emacs executable

[Ken Raeburn]

On Apr 19, 2013, at 15:05, Eli Zaretskii <eliz@gnu.org> wrote:
> That's a different issue.  My question was about what "make install"
> does with DOC, not what "make emacs" does in src.  We can install DOC
> under the name DOC-XX.YY.ZZ without changing what happens in src and
> in etc of the build tree.

I've long wondered if it would be better to get rid of the DOC file altogether and keep the documentation in the executable image.

With GCC and ELF systems, it's not that hard to compile the C doc strings into a specially named section so they're segregated from other Emacs data, so on a modern demand-paging system they can still be left out of the process working set unless they're actually used, and shared between processes, although it still makes the executable look huge.  As for preloaded Lisp, maybe the doc strings can be made pure strings; maybe we could just save the location of the doc strings, as would be done for Lisp code loaded later.

Or take the easy way out -- have make-docfile generate a really big C source file with a const char array (or an array of strings) instead of a text file, and "read" the doc strings from there.

The quick-hack version I did of the first part (compiling in C doc strings from DEFUN/DEFVAR) seemed to work pretty well on GNU/Linux (special ELF section for doc strings) and Mac OS X (ordinary const char arrays), though I haven't had a lot of time for finishing it.  I don't know if it would cause any trouble for Windows to have all those extra strings in the executable image, or if it would be hard (or helpful) to segregate them.

Ken

Re: Installing the Emacs executable

[Stefan Monnier]

>> That's a different issue.  My question was about what "make install"
>> does with DOC, not what "make emacs" does in src.  We can install DOC
>> under the name DOC-XX.YY.ZZ without changing what happens in src and
>> in etc of the build tree.

A simpler solution is to drop the DOC-XX.YY.ZZ and only use a single
"DOC" file.  I've been doing that quite happily for years now.

> I've long wondered if it would be better to get rid of the DOC file
> altogether and keep the documentation in the executable image.

That could be an option.  There are various ways this could be done, but
I think it would only be worth it if it can simplify the code.

Given the fact that we'd most likely still need to keep most of the
current code to lazy-load docstrings/bytecode from those .elc files that
are not preloaded, I think it'll be difficult to come up with something
that simplifies the code.


        Stefan

Re: Installing the Emacs executable

[Eli Zaretskii]

> From: Ken Raeburn <raeburn@raeburn.org>
> Date: Wed, 24 Apr 2013 01:05:07 -0400
> Cc: emacs-devel@gnu.org
> 
> On Apr 19, 2013, at 15:05, Eli Zaretskii <eliz@gnu.org> wrote:
> > That's a different issue.  My question was about what "make install"
> > does with DOC, not what "make emacs" does in src.  We can install DOC
> > under the name DOC-XX.YY.ZZ without changing what happens in src and
> > in etc of the build tree.
> 
> I've long wondered if it would be better to get rid of the DOC file altogether and keep the documentation in the executable image.
> 
> With GCC and ELF systems, it's not that hard to compile the C doc strings into a specially named section

Beware: you might get into the same situation that the Windows build
is today -- you will be unable to strip the resulting executable as
part of "make install-strip", because 'strip' doesn't know anything
about the section you add.

In any case, I thought the tendency was to stay away of tricks that
are too specific to binary formats, to avoid re-living the unexec
problem...

Re: Installing the Emacs executable

[Stefan Monnier]

> In any case, I thought the tendency was to stay away of tricks that
> are too specific to binary formats, to avoid re-living the unexec
> problem...

It shouldn't be too hard to come up with a solution that does not rely
on tricks.  Or at least, no new tricks.  E.g. store the preloaded
docstrings in a second "pure heap" (we could even just use the existing
pure heap, but if we want to keep those VM pages on disk, we'd like to
keep them "geographically" separate).


        Stefan