Byte compilation error.

[Teika Kazura <teika lavabit com>]

Hi, I've stopped the previous thread to make it clear that the
Harald's patch is the official fix.

Now, let me review the problem, one by one.

1. Sawfish-1.6.3 byte compilation fails since commit 2277ff on Mar 13,
at the compilation of wm/util/prompt.jl. If it is compiled after other
prompt*jl, then it succeeds. But that commit itself is faultless, it
only revealed a new problem as we see below.

The compilation order is not related to multi-threads. Lisp function
'compile-lib-batch' uses 'directory-files' which returns *unsorted*
list of files. This is the cause of the randomness.  Thus, a fix is
needed, and any which works is ok. I've chosen the first one.

I don't know why in my case it was alphabetical order. I've compiled 7
times since Mar 13, so it must be always so in my environment.

2. Other fixes, (a) deleting eval-when-compile (b) require inside
eval-when-compile, also work.

3. Byte compilation. (This is for Lisp fans.)
Jeremy understands lisp far better than me, but he's confused
with byte compilation. Let me tell you what I've learned.

'requiring itself' does nothing. It's already opened.  But it's byte
compiler (Herafter 'bc')! A bc is *NOT* a lisp interpreter. A silly
but easy example of bc is something like a preprocessor, deleting
comments, redundant whitespaces, etc. It has almost nothing to do with
lisp. Of coures, librep bc is far more complex, but it does not evaluate
the file.

The bc opens other modules to check exported functions, defvars, and
so on. So, (require 'prompt) is the first open, not the second whih
opens itself. It's natural to assume defvar's in prompt.jl should be
evaluated at compilation of prompt.jl, but it's not. This is the whole
story.

4. So, what to do?
We can sweep this issue under the carpet, but if it's to be fixed,
Jeremy's patch is the only meaningful way. But he says it's not yet
complete, so let me conclude that's all for today. ;) We've got other
issues now.

Teika (Teika kazura)