MacOS?

[Stephen J. Turnbull]

Mats Lidell writes:

 > At times though I have been thinking about whether a source code based
 > package system would make sence. Things that spring to my mind are:
 >  - doing the byte compilation locally so that the right byte code is
 >    generated naturally. The same Emacs used for running the package is
 >    also used for compiling it.

We haven't had any byte-code compatibility problems with the policy of
compiling under 21.4.  In general compiling under a particular XEmacs
would mean that people with multiple installations of XEmacs would not
be able to share packages among them.

On the other hand, I think eventually we should move to compiling
on-the-fly like Python and Perl.  That would mean the same thing, for
the same reason.

 >  - the build would handle Emacs properties like mule or nonmule
 >    depending on what version of Emacs is used for the build.

They're not actually relevant to the byte code.  The issue is simply
whether the XEmacs doing the compilation can read multibyte characters
or not.  I'm pretty sure that a no-mule XEmacs can correctly compile
Lisp that requires Mule to execute as long as all non-ASCII characters
and strings are built up with `make-character' etc.  I think this is
true in general!

 >  - at the same time construct the package system to handle
 >    dependencies properly between packages, including dependencies to
 >    the Emacs binary.

I'm not sure what you mean by "dependencies on the Emacs binary".
(See previous point.)  Dealing with Lisp dependencies, though, is
pretty hard, because Lisp doesn't really provide anything beyond
autoload and require to deal with them: everything just lives on the
load-path.  The big problem is that you can compile a library
successfully without having its prerequisites present, *except* for
macros, which must be defined in the compilation environment.  But you
can't know which "functions" are actually implemented as macros (and
it might even change across versions of Emacs).

 >  - support for third party packages.

Again, the problem is dealing with dependencies.