Re: Compilation cleanup

[Martin S. <ma...@ly...>]

Martin Buchholz <ma...@xe...> wrote:

> The following patch eliminates *all* warnings when byte-compiled using
> XEmacs 21, pre-release Emacs 21 and Emacs 19.34.

Thanks, I've looked closely at this now. It's a quite interesting
exercise to do tricks with evaluation during compilation, although I
still think it's wrong that an application should have to do these
things; the byte compiler ought to provide the facilities for all of
it.

Anyway, I ended up changing just about everything, mainly to get a
decentralized system where the byte compilation helper file doesn't
contain any knowledge about the symbols or files of the rest of CC
Mode. It provides what I think the byte compiler should provide
itself:

o  Load everything from source files during compilation (a cc-require
   replacement for the require form).
o  Disable compiler warnings with simple declarations, e.g.
   (cc-bytecomp-defvar zmacs-regions).

It's a bit interesting what kind of problems can show up with the
current compilation system (in all Emacsen); I compared the compiled
files which I got from compiling them all at once and compiling them
each in a separate process and found a bug due to macro definition
order. Afaics the bug has been there a long time, but hasn't been
discovered since the files often are compiled in a certain order
within the same Emacs session.

> It patches the Emacs 19 byte-compiler to do sensible things with
> (char-after).

That was a bit of black magic. ;) I'd like to do the same for XEmacs
19, but I couldn't find out a way to detect that case which I could
live with (the problem there is that char-after accepts zero
arguments, but the byte compiler definition still requires at least
one).

> Since lexical variables are in general preferable, you might consider
> replacing the existing uses of dynamic vars for "private" variables
> within the code.

Yes, that'd be more clean.

> XEmacs byte-compiler didn't like redefining a subr with a macro, hence
> cc-mode19.el makes char-before a function.  There's no advantage to
> having macros used at runtime, so it makes more sense anyways.

I don't understand this one. It wouldn't work if it was a macro only
at runtime, and it does indeed get expanded at compile time. I also
had no problems with any XEmacs version I tested (19.16, 20.4 and
21.1.10).

If you want I can send you the patches I ended up with, or you can
look at it in the anonymous cvs from SourceForge (see
cc-mode.sourceforge.net for the details).

Since I've completely revamped your patch I don't think it's required
that you to sign the FSF legal papers for this, but it'd be nice if
you did that anyway, so I can credit you duly without problems. (I'll
get back to you about this, provided you're still interested in doing
it, when I've gotten the texts I need from the FSF.)

Btw, thanks for your perl script for finding dependencies; I've used
it to clear up the dependency tree quite a bit (although cc-mode.el
still loads the world; it's not possible to do much about that). I
modified the script to detect both compile-time and runtime
dependencies, since require:s are used for both. It's attached below
(the bit which handles backquoted sexps is a bit overkill; I mainly
did it as a fun excercise in abusing perls regexp engine ;).