Re: MacOS?

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 _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta