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

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

[debbugs-tracker] bug#26459: closed (26.0.50; loaddefs.el is regenerated


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#26459: closed (26.0.50; loaddefs.el is regenerated after each "git pull")
Date: Thu, 13 Apr 2017 07:07:01 +0000

Your message dated Thu, 13 Apr 2017 10:06:17 +0300
with message-id <address@hidden>
and subject line Re: bug#26459: 26.0.50; loaddefs.el is regenerated after each 
"git pull"
has caused the debbugs.gnu.org bug report #26459,
regarding 26.0.50; loaddefs.el is regenerated after each "git pull"
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
26459: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=26459
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 26.0.50; loaddefs.el is regenerated after each "git pull" Date: Wed, 12 Apr 2017 11:54:00 +0300
To reproduce:

  $ touch .git/logs/HEAD
  $ make

and observe loaddefs.el being regenerated for no good reason.

Generation of loaddefs.el is annoyingly slow (takes more than 1 minute
on a fast machine, almost 2 min on fencepost.gnu.org), so running it
on every pull should be avoided.

The reason for this are two rules.  One is in src/Makefile.in:

  $(lispsource)/loaddefs.el: $(VCSWITNESS) | bootstrap-emacs$(EXEEXT)
          $(MAKE) -C ../lisp autoloads EMACS="$(bootstrap_exe)"

This triggers each "git pull" due to $(VCSWITNESS).

The other rule is in lisp/Makefile.in:

  autoloads .PHONY: $(lisp)/loaddefs.el

Why should loaddefs.el be treated as a "phony" target?  It's a real
file.  This was introduced in d703a4d, whose log message says just
this:

    * lisp/Makefile.in (PHONY_EXTRAS): New macro.
    (.PHONY): Depend on it, and on $(lisp)/loaddefs.el, so that the
    relevant files' time stamps are ignored.

That says nothing about the rationale, and I couldn't find any
discussions of the change.  Paul, could you please explain why would
it be a bad idea to remove the "phony" status from loaddefs.el?

In GNU Emacs 26.0.50 (build 414, i686-pc-mingw32)
 of 2017-04-12 built on HOME-C4E4A596F7
Repository revision: 449bc49c768a4733411c7e05186be7efc163cd7c
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --prefix=/d/usr --enable-checking=yes,glyphs --with-wide-int
 --with-modules 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS MODULES

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message puny seq byte-opt subr-x gv
bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib
dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript case-table epa-hook jka-cmpr-hook help
simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote w32notify w32 multi-tty make-network-process emacs)

Memory information:
((conses 16 102469 10783)
 (symbols 56 21160 1)
 (miscs 48 36 108)
 (strings 16 21253 4892)
 (string-bytes 1 601609)
 (vectors 16 14701)
 (vector-slots 8 479332 4573)
 (floats 8 50 86)
 (intervals 40 267 79)
 (buffers 864 11))



--- End Message ---
--- Begin Message --- Subject: Re: bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull" Date: Thu, 13 Apr 2017 10:06:17 +0300
> From: Glenn Morris <address@hidden>
> Cc: address@hidden,  address@hidden, address@hidden
> Date: Wed, 12 Apr 2017 12:43:01 -0400
> 
> Eli Zaretskii wrote:
> 
> >> IIUC 440bafe has made this much slower by defeating the prior "only
> >> update where needed" aspect of this.
> >
> > 440bafe made the rule generate the loaddefs in a temporary file.
> > Would it help to copy loaddefs.el into loaddefs.tmp before running
> > batch-update-autoloads?
> 
> Probably, together with a move-if-change at the end.

Done in 88e0125.  Generating loaddefs.el is fast again ;-)



--- End Message ---

reply via email to

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