Re: erroneous byte-compilation during build process?

[Stephen Berman <Stephen.Berman@gmx.net>]

On Tue, 2 May 2006 12:46:47 -0700 (PDT) "Stuart D. Herring"
<herring@lanl.gov> wrote: 

>> The two recentf.elc files -- the one made by the build process and
>> the one I byte-compiled from source -- differ in almost every line,
>> as shown by diff -a, but I don't know what the differences mean: as
>> far as I can tell, they only differ in cons cells like this:
>>
>> 19c19
>> < (defvar recentf-list nil (#$ . 677))
>> ---
>> > (defvar recentf-list nil (#$ . 671))
>
> If these are the only changes, they're entirely irrelevant; the numbers
> just indicate the places in the file where the documentation can be found.
>  The difference is probably a difference in the length of the file name
> given in the comment block at the top.  Check for other differences, or
> make the file/path names the same length for testing.

Thanks for the pointer.  Now the diff -a output is much smaller, and
it was easy to spot the differences; in fact, the very first diff of
byte-compiled functions is the function where the error arises:

2c2
< ;;; Compiled by steve@escher.local.home on Sun Apr 16 17:30:57 2006
---
> ;;; Compiled by steve@escher.local.home on Tue May  2 23:06:58 2006
426c426
< (defalias 'recentf-open-files #[(&optional files buffer-name) "\b\204\f\0	\204\f\0\306\307!\210r\310\n\206\x16\0\311\312\v\"!q\210\313\314 \x1c\x1d\315\316\f@\"\210\315\316\fA\"\210\317 \210*\320 \210\321\322\x0e.\203<\0\323\202=\0\324\325\326$\210\327\211\x1e/\x0e\x1a\205N\0\x0e\x1a\330H\230\204b\0\331\332!\210\333\334\335\"\211\x16\x1a\330\x0e/I\210)\336\337\340\341\342\343\344\345\b\206p\0	!BBBBB\"\210\337\346\347\350\351$\210\352\353!\210\354 \210\355p!)\207" [files recentf-list buffer-name recentf-menu-title ol inhibit-read-only error "There is no recent file to open" get-buffer-create format "*%s*" t overlay-lists mapc delete-overlay erase-buffer recentf-dialog-mode widget-insert "Click on a file" ", or type the corresponding digit key," "" " to open it.\n" "Click on Cancel or type `q' to cancel.\n" "folder" 0 make-local-variable tree-widget--theme make-vector 4 nil apply widget-create group :indent 2 :format "\n%v\n" recentf-open-files-items push-button :notify recentf-cancel-dialog "Cancel" recentf-dialog-goto-first link widget-setup switch-to-buffer recentf-show-file-shortcuts-flag name] 10 (#$ . 43202) nil])
---
> (defalias 'recentf-open-files #[(&optional files buffer-name) "\b\204\f\0	\204\f\0\306\307!\210r\310\n\206\x16\0\311\312\v\"!q\210\313\314 \x1c\x1d\315\316\f@\"\210\315\316\fA\"\210\317 \210*\320 \210\321\322\x0e)\203<\0\323\202=\0\324\325\326$\210\327\330!\210\331\332\333\334\335\336\337\340\b\206R\0	!BBBBB\"\210\332\341\342\343\344$\210\345\346!\210\347 \210\350p!)\207" [files recentf-list buffer-name recentf-menu-title ol inhibit-read-only error "There is no recent file to open" get-buffer-create format "*%s*" t overlay-lists mapc delete-overlay erase-buffer recentf-dialog-mode widget-insert "Click on a file" ", or type the corresponding digit key," "" " to open it.\n" "Click on Cancel or type `q' to cancel.\n" tree-widget-set-theme "folder" apply widget-create group :indent 2 :format "\n%v\n" recentf-open-files-items push-button :notify recentf-cancel-dialog "Cancel" recentf-dialog-goto-first link widget-setup switch-to-buffer recentf-show-file-shortcuts-flag] 9 (#$ . 43202) nil])

These differ only in the last few hundred characters, specifically
here:

< "folder" 0 make-local-variable tree-widget--theme make-vector 4 nil
---
> tree-widget-set-theme "folder"

and here:

< recentf-show-file-shortcuts-flag name] 10
---
> recentf-show-file-shortcuts-flag] 9

(Subsequent differences in the diff -a output are only in the
documentation cons cells, evidently due to the differing lengths of
the above pieces of byte compiled code.)  In fact, the first
difference shows the reason for error I was getting (a missing call to
tree-widget-set-theme).  So this seems to prove that the original
byte-compilation of recentf.el, produced by the build process, is
erroneous.  The question remains, how did this happen?  Why did the
Emacs build process yield an erroneous byte compilation, while my byte
compilation of the same source yielded a correct one?

Steve Berman