Martin Buchholz <martin(a)xemacs.org> wrote:
> I believe it rather evil that the cc-mode elisp files need special
> compilation support.
I agree it's not a very good situation, and as you can see at the top
of the relevant CC Mode files I've tried to add some code to fix it:
(eval-when-compile
(let ((load-path
(if (and (boundp 'byte-compile-current-file)
(stringp byte-compile-current-file))
(cons (file-name-directory byte-compile-current-file)
load-path)
load-path)))
(load "cc-defs" nil t)))
I'm aware that it doesn't work all the time; it seems like
byte-compile-current-file doesn't always get set (can't remember
exactly when and why it didn't work). I remembered I tried a couple of
different ways and this was the best I could come up with. If you know
a more failsafe solution I'd be happy to use it.
Besides, don't you have to do special treatment of other multifile
packages already? Gnus and calc comes to mind, and a quick look in the
calc sources reveal no measures to ensure that the correct macros are
loaded at compile time.
> In 1996, both I and a colleague of mine encountered the bug of
> cc-mode elisp files not being properly compiled. I believe in 1996
> or 1997 I submitted a patch to cc-mode that fixes all the .el files
> that are part of that package so that each can be independently
> bytecompiled without warnings, and by both emacs and xemacs.
That patch must've been submitted before I started working as
maintainer.
I've done some work reducing the number of warnings, and it's possible
to eliminate almost all of them if you sacrifice compiled file
compatibility between Emacs and XEmacs. Although I personally wouldn't
count on such compatibility in any case, it became apparent that some
people actually use it - I had to roll back those changes.
So the warnings that are left are all there for good reasons; the
problems that arises from fixing them are not considered worth it. I'd
say that they should be fixed in the compiler instead, by introducing
a pragma construct to turn them off in specific places and/or making
the compiler smarter. E.g. a smart compiler wouldn't warn about using
an unbound variable in this case:
(if (boundp 'this-variable-exists-in-xemacs-only)
(do-something this-variable-exists-in-xemacs-only))
> If autoload cookies are acceptable to the package maintainers, then
> (completely untested)
>
> ;;;###autoload
> (unless (rassq 'pike-mode auto-mode-alist)
> (setq auto-mode-alist (append auto-mode-alist
> '(("\\.\\(u?lpc\\|pike\\|pmod\\)\\'" . pike-mode)))))
>
> The above has the advantage that:
>
> - It's much more efficient to compare the symbols than the strings
> - you never get duplicate entries in auto-mode-alist
> - the entries are appended, rather than prepended, so the user's
> settings get precedence.
> - control is centralized in the package sources.
Good idea. Generally I believe it's better if common variables never
change at package load time, since different loading orders can
produce different results. However in this case I can't directly see
how that could be a problem, but I still think I'd go for a solution
that doesn't change auto-mode-alist at load time, to be on the safe
side:
;;;###autoload (setq auto-mode-alist
;;;###autoload (cons '("\\.\\(u?lpc\\|pike\\|pmod\\)\\'" . 'pike-mode)
;;;###autoload auto-mode-alist))
The effect of this would afaics be practically identical to
maintaining a global auto-mode-alist default value. Since the code is
executed at dump time, there's no need to check for prior settings and
append to the variable. The only issue would be to ensure that the
defvar for auto-mode-alist has been executed before loaddefs.el so
that the prior default value doesn't get lost (which is a potential
problem in your solution as well, btw).
If this alternative is ok, I think I'd prefer to register the file
extensions for all the CC Mode languages this way. Then I instead
would like those entries be removed from the standard auto-mode-alist
value (although it wouldn't be necessary). But before I can do such a
change, I have to check if this sits well with the GNU Emacs folks
too.
