Red Hat Bugzilla – Bug 474958
update-directory-autoloads broken
Last modified: 2013-01-09 23:57:46 EST
Description of problem: autoloads can't be rebuilt by and end user because update-directory-autoloads references a temporary rpm build-time path. Version-Release number of selected component (if applicable): emacs.x86_64 1:22.2-5.fc9 How reproducible: every time Steps to Reproduce: 1. add ";;;###autoload" above a random defun in the emacs el sources 2. type M-x update-directory-autoloads 3. notice it chokes with: Loading autoload...done autoload-ensure-default-file: Opening output file: no such file or directory, /builddir/build/BUILD/emacs-22.2/lisp/loaddefs.el Actual results: building a new set of autoloads fails Expected results: building a new set of autoloads is expected to work. Additional info: Some days are like this. Attempting to fix a missing autoload for vm-decode-postponed-mime-message and I'm recursing deeper into emacs breakage. I'm not sure I understand the rpm-build goop enough to go any further.
The problem is, that emacs compiles the .el files while we build the rpm, so the path inside them is $RPM_BUILD_ROOT instead of the dir, where it will be after installation. When I write there the right path, where they will reside, emacs can't find it while building :( ... I will analyze, if we can build in chroot (don't know if that's possible) or use some other way the compiled-in path will be right.
I see now there's --enable-locallisppath option to ./configure, I will see if it does what we want
*** Bug 522746 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > I see now there's --enable-locallisppath option to ./configure, I will see if > it does what we want nope, that didn't help us
a piece of advice came from the emacs mailing list: the path, which is used there, is in the "source-directory" variable, so you can do something like (let ((source-directory "/usr/share/emacs/23.1/lisp/")) (update-directory-autoloads "/path/to/scan/for/autoload/cookies")) The important thing is that `update-directory-autoloads' wants to write its output to (concat source-directory "lisp/loaddefs.el") I will try to find some way to incorporate this change into the Fedora Emacs package.
(In reply to comment #5) > (let ((source-directory "/usr/share/emacs/23.1/lisp/")) > (update-directory-autoloads "/path/to/scan/for/autoload/cookies")) actually (source-directory "/usr/share/emacs/23.1/") works here. the "/lisp" is added afterwards by emacs
Seems setq-ing the variable in site-lisp.el fixes the problem.
(In reply to comment #7) > Seems setq-ing the variable in site-lisp.el fixes the problem. site-start.el of course
I fixed this in rawhide (emacs-23.1-13.fc13) if someone desperately wants a fix for an older release, please let me know, but all you need to do to fix this is to have (setq source-directory "/usr/share/emacs/23.1/") in a startup file
emacs-23.1-19.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/emacs-23.1-19.fc12
emacs-23.1-11.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/emacs-23.1-11.fc11
emacs-23.1-13.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/emacs-23.1-13.fc11
emacs-23.1-13.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.