emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] Problem with autoloads


From: Michael Markert
Subject: Re: [O] Problem with autoloads
Date: Tue, 28 Jun 2011 14:39:13 +0200
User-agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.0 Mule/6.0 (HANACHIRUSATO)

On 28 Jun 2011, Michael Markert wrote:

> [1  <text/plain; US-ASCII (7bit)>]
> On 28 Jun 2011, Nick Dokos wrote:
>> <snip>
>>
>> Suvayu and I worked on this in an email exchange: it turns out that
>> Michael was right in that (recent) emacs 24 is indeed the culprit. In
>> particular, the variable generated-autoload-file is now initialized
>> to nil:
>>
>> ,----
>> | (defvar generated-autoload-file nil
>> |   "File into which to write autoload definitions.
>> | A Lisp file can set this in its local variables section to make
>> | its autoloads go somewhere else.
>> |
>> | If this is a relative file name, the directory is determined as
>> | follows:
>> |  - If a Lisp file defined `generated-autoload-file' as a
>> |    file-local variable, use its containing directory.
>> |  - Otherwise use the \"lisp\" subdirectory of `source-directory'.
>> |
>> | The autoload file is assumed to contain a trailer starting with a
>> | FormFeed character.")
>> `----
>>
>> whereas before (e.g. in the version of emacs 24 that I'm running: GNU
>> Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of
>> 2011-04-13) it was initialized to "loaddefs.el":
>>
>>
>> ,---- | (defvar generated-autoload-file "loaddefs.el" | "*File
>> \\[update-file-autoloads] puts autoloads into.  | A `.el' file can
>> set this in its local variables section to make its | autoloads go
>> somewhere else.  The autoload file is assumed to contain a | trailer
>> starting with a FormFeed character.")  `----
>>
>> The particular value is not that important: the fact that it was
>> a relative file name is, as indicated by the comment above.
>>
>> I think the following patch fixes it and does not break any earlier
>> versions of org. Suvayu, Michael (and anybody else who cares to try
>> it): would you mind checking and reporting back?

With this patch for the makefile I can get it running:

-- <snap> ---

diff --git a/Makefile b/Makefile
index 239ab2e..2d1d324 100644
--- a/Makefile
+++ b/Makefile
@@ -230,12 +230,11 @@ autoloads: lisp/org-install.el

 lisp/org-install.el: $(LISPFILES0) Makefile
        $(BATCH) --eval "(require 'autoload)" \
-               --eval '(find-file "org-install.el")'  \
+               --eval '(find-file "lisp/org-install.el")'  \
                --eval '(erase-buffer)' \
-               --eval '(mapc (lambda (x) (generate-file-autoloads (symbol-name 
x))) (quote ($(LISPFILES0))))' \
+               --eval '(mapc (lambda (x) (generate-file-autoloads (symbol-name 
x))) (quote ($(LISPF))))' \
                --eval '(insert "\n(provide (quote org-install))\n")' \
                --eval '(save-buffer)'
-       mv org-install.el lisp

 doc/org: doc/org.texi
        (cd doc && $(MAKEINFO) --no-split org.texi -o org)

-- <snap> ---

I have some problems with writing org-install directly but otherwise
autoload.el generates lisp/ autoloads (with LISPFILES0) or fails to find
(with LISPF).

But because org-install is automatically generated I don't consider them
as such grave in the case it kills the old file and leaves garbage
(maybe use a backup file?).

I tried several things that all failed:
1. Let-bind `generated-autoload-load-name' per run
2. add `generated-autoload-file' to the elisp files
3. 1. with LISPFILES0
4. ...

I'll spare you the rest. :(

Michael

Attachment: pgpX5XgNWdHfb.pgp
Description: PGP signature


reply via email to

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