Question

[Stephen J. Turnbull]

Carsten Dominik writes:

 > For supporting different languages, we will have a few emacs lisp
 > files which should not be compiled because the have dependencies on
 > code that is not present in Emacs.  I.e. they do something like
 > 
 >     (require 'slime)

This is not a problem, unless it's within `eval-when-compile'.  Go
ahead and compile it otherwise.

 > and call lots of functions from this package.

For *functions*, this isn't a problem, either.  However, *macros* from
the slime library must be defined at compile time, because Emacs byte
code doesn't know how to expand and reevaluate macros.  (IIRC, anyway,
for sure XEmacs's bytecode interpreter can't do that.)  Instead, the
macro is expanded, then the expansion is compiled at compile time.

 > I think the best way it to leave these files uncompiled.

I feel sick ... ok, it got better.  No, this is rarely a good idea.
If you have only functions, it's pointless.  If you have macros, then
remember that macros get evaluated twice: once to generate code, and
once to evaluate the generated code.  The function that generates the
expansion is rarely very efficient because it is expected to be
expanded once at compile time.  Instead it is normally written to be
as straightforward an expression of the desired expansion code as
possible.  IOW, you're likely to impose a perceptible performance hit
on those users.

Since org-mode is now part of Emacs, third party packages can assume
it will be available, and if leaving files uncompiled seems your only
option, then it's probably best all-around to contribute that code to
the third-party package, and have it compiled there.