MacOS?

[Mats Lidell]

>>>>> Stephen wrote:

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

True but I never said the package system would be for XEmacs only.

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

Yes, that would be a nice.

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

Well a package system is not only for byte compilation but also for
giving a user a reasonable list of available packages. Packages that
can't be used with the Emacs at hand should not be possible to
install. So a mule package will not be available to a non mule XEmacs
for example.

Stephen> I'm not sure what you mean by "dependencies on the Emacs
Stephen> binary".

I mean that a specific version of a package might not be available for
all versions of the binaries. Like the current problem with ecb. It
doesn't work with 21.5. If there is an older version of ecb that works
with 21.5 that version is the one that a 21.5 user will see.

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

Yes, and it is here I start to wonder whether it will be worth
it. Lisp is pretty good in it self to handle dependencies and
sometimes a package is useful although some part of it depends on
something that isn't available.

Still some packages do come with a list of things that must be
available for it to work and that type of dependencies could be
handled.

But no, I don't plan on doing something like this. It was just
something I thought about when helping out a little with the xemacs
packages for gentoo.

Yours
-- 
%% Mats