bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#66022: 30.0.50; kmacro overwriting global keybindings


From: Gerd Möllmann
Subject: bug#66022: 30.0.50; kmacro overwriting global keybindings
Date: Wed, 20 Sep 2023 11:57:28 +0200
User-agent: Mozilla Thunderbird

On 23-09-18 20:24 , Stefan Monnier wrote:
Do you think the following plan make ssense?

- I assume that a build from git clean -xdf shows all the steps that
must happen with 100% certainty.

- I'd then make bootstrap + look for a difference.

- Then same procedure for simple make in the toplevel dir,
    - after there is only a C file changed
    - after only a Lisp file is changed

Sounds good.

You might also want to compare the timestamp of `loaddefs.elc` compared to
the timestamp of `emacs.pdmp` in your build directory (assuming you
still have it around).

I think I've found something.

Assume I git pull, and emacs-lisp/comp.el is modified in a way that loaddefs gets regenerated and written to disk. Then do a toplevel gmake. After that, I see the following:

~/emacs/master/ > ll lisp/loaddefs.el* src/emacs.pdmp lisp/emacs-lisp/comp.* nextstep/Emacs.app/Contents/Resources/lisp/loaddefs* nextstep/Emacs.app/Contents/MacOS/libexec/Emacs.pdmp
-rw-r--r--  1 gerd  staff   1.4M Sep 20 11:31 lisp/loaddefs.el
-rw-r--r--  1 gerd  staff   1.4M Sep 20 11:32 lisp/loaddefs.elc
-rw-r--r--  2 gerd  staff    16M Sep 20 11:32 src/emacs.pdmp
-rw-r--r--  1 gerd  staff   188K Sep 20 11:31 lisp/emacs-lisp/comp.el
-rw-r--r--  1 gerd  staff   399K Sep 20 11:32 lisp/emacs-lisp/comp.elc
-rw-r--r-- 1 gerd staff 369K Sep 20 10:55 nextstep/Emacs.app/Contents/Resources/lisp/loaddefs.el.gz -rw-r--r-- 1 gerd staff 1.4M Sep 20 10:56 nextstep/Emacs.app/Contents/Resources/lisp/loaddefs.elc -rw-r--r-- 1 gerd staff 16M Sep 20 11:32 nextstep/Emacs.app/Contents/MacOS/libexec/Emacs.pdmp

Note that the pdmp in Emacs.app is new, while the loaddefs under nextstep are old.

After gmake install:

~/emacs/master/ > ll lisp/loaddefs.el* src/emacs.pdmp lisp/emacs-lisp/comp.* nextstep/Emacs.app/Contents/Resources/lisp/loaddefs* nextstep/Emacs.app/Contents/MacOS/libexec/Emacs.pdmp
-rw-r--r--  1 gerd  staff   1.4M Sep 20 11:31 lisp/loaddefs.el
-rw-r--r--  1 gerd  staff   1.4M Sep 20 11:32 lisp/loaddefs.elc
-rw-r--r--  2 gerd  staff    16M Sep 20 11:32 src/emacs.pdmp
-rw-r--r--  1 gerd  staff   188K Sep 20 11:31 lisp/emacs-lisp/comp.el
-rw-r--r--  1 gerd  staff   399K Sep 20 11:32 lisp/emacs-lisp/comp.elc
-rw-r--r-- 1 gerd staff 369K Sep 20 11:31 nextstep/Emacs.app/Contents/Resources/lisp/loaddefs.el.gz -rw-r--r-- 1 gerd staff 1.4M Sep 20 11:32 nextstep/Emacs.app/Contents/Resources/lisp/loaddefs.elc -rw-r--r-- 1 gerd staff 16M Sep 20 11:32 nextstep/Emacs.app/Contents/MacOS/libexec/Emacs.pdmp

Means to me that if I just gmake, expecting that could not possibly change Emacs.app, I'm quite mistaken. Instead, I now have an inconsistent Emacs.app.

Does that make sense?

Has someone maybe an idea why the pdmp gets installed so early?






reply via email to

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