Re: Reworking loaddefs.el generation

[Lars Ingebrigtsen <larsi@gnus.org>]

Eli Zaretskii <eliz@gnu.org> writes:

> I see this with the current master:
>
>   $ touch lisp/array.el .git/logs/HEAD
>   $ make -j4
>   [...]
>     GEN      loaddefs.el
>     INFO     Scraping files for loaddefs...
>     INFO     Scraping files for loaddefs...26%
>     INFO     Scraping files for loaddefs...53%
>     INFO     Scraping files for loaddefs...81%
>     INFO     Scraping files for loaddefs...done
>     GEN      loaddefs.el
>
> Why so much "scraping" lines for just one file modified?

I get

  GEN      loaddefs.el
  INFO     Scraping files for loaddefs... 
  INFO     Scraping files for loaddefs...done
  GEN      loaddefs.el

in that test case.

The loop is:

      (dolist (file files)
        (progress-reporter-update progress (setq file-count (1+ file-count)))
        (when (or (not updating)
                  (file-newer-than-file-p file output-file))
          <scrape>

So it seems like file-newer-than-file-p is very slow on your machine
since progress-reporter manages to output several percentages?

> And the example which was before my eyes when I wrote the above was
> actually this:

[...]

>     GEN      loaddefs.el
>     INFO     Scraping files for loaddefs...
>     INFO     Scraping files for loaddefs...10%
>     INFO     Scraping files for loaddefs...20%
>     INFO     Scraping files for loaddefs...30%
>     INFO     Scraping files for loaddefs...40%

[...]

>     ELC      emacs-lisp/loaddefs-gen.elc

Yes, when loaddefs-gen is newer than lisp/loaddefs.el, it regenerates
all the loaddefs files (both to avoid problems with old-style loaddefs
files and to force updates if there's a bug in loaddefs-gen itself).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no