[Top][All Lists]

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

Re: reftex.el autoloads

From: Phillip Lord
Subject: Re: reftex.el autoloads
Date: Sat, 19 Dec 2015 13:24:20 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> The intuitive solution is do
>> $(lisp)/loaddefs.el $(lisp)/textmodes/reftex-loadefs.el 
>>      @echo Directories for loaddefs: ${SUBDIRS_ALMOST}
>>      $(AM_V_GEN)$(emacs) -l autoload \
>>          --eval '(setq autoload-ensure-writable t)' \
>>          --eval '(setq autoload-builtin-package-versions t)' \
>>          --eval '(setq generated-autoload-file (expand-file-name 
>> (unmsys--file-name "$@")))' \
>>          -f batch-update-autoloads ${SUBDIRS_ALMOST}
>> but this fails because make actually runs batch-update-autoloads
>> multiple times which is both wasteful and causes a race condition with
>> -j.
> Several alternative solutions for this were tried, and all of them
> were found out as worse than the problem.

Indeed. It's something make just does not support well. The only
solution I have is to add makefile rules for each -loaddefs.el file
listing all dependencies. They don't change that often, so it's
possible, but I don't think it is worth it.

As I said at the beginning, personally, for the small files, I would
have placed the autoloads into loaddefs.el, and for the bigger files
(dired.el, reftex.el and ibuffer) I would remove this mechanism and
replace it with a simple require.

>> As this doesn't work, I didn't do it (I tried it!). Instead, I added
>> autoloads-force. It's ugly, but it's explicit and ugly rather than
>> implicit and ugly.
> This has never been a problem in practice, so I don't think that
> additional rule is needed.

I used it repeatedly to make the commits, and anyone adding new
autoloads to any of the autoloaded files would find it useful. And the
comment is more useful -- it too me a while to work out why the loaddefs
files where NOT being produced by make autoloads

But, feel free to remove it, if you wish. It's not a big deal.


reply via email to

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