Re: byte-compile emu-mule.el

Stephen> I would like to purge code that requires Mule to build Stephen> correctly from the main codebase. SY> Please don't. Having packages split across two different SY> places will make maintenance a bitch. "Purge" doesn't necessarily mean physically move (or remove), although that's what Yoshiki and I recommended for APEL's emu-mule. The problem is that _code containing Mule characters is not Lisp_ as far as a --with-mule=no XEmacs is concerned. A README.mule really isn't sufficient for this. Attempting to load such a file leaves Lisp in an undefined (from the user's point of view) state: definitions and top-level code encountered before the top-level sexp containing the first Mule character _will_ have been executed, except that function definitions and provides will get unwound in the case of an autoload. I have three different approaches in mind o physically move the code to a separate package directory, probably with the same name, under xemacs-packages/mule o physically move the code to a mule subdirectory of the original package o physically move the code to a separate file with an extra extension (.mule should do the trick) In the former case, we'd need to create a separate package; that probably is a distribution nightmare, so it probably hardly ever makes sense. The last is probably the best idea; there actually is very little code that really requires Mule. Then XEmacs.rules would get a rule to make a .el file from a .el.mule file by renaming or copying it. APA> But APA> make distclean APA> make bindist APA> isn't really asking too much of people who want to build APA> their own packages, I think. Actually, it's a fair amount. It's often quite hard to determine which packages you need ex ante, so basically you end up checking out the whole xemacs-packages tree. This could probably be mostly fixed with a dependency chaser, but most package build bugs reported seem to be due to dependency bugs in one form or another. APA> Having to copy xemacs-packages/Local.rules.template to APA> xemacs-packages/Local.rules and configuring it correctly is APA> the trickiest part. I hate that name; there are no Make rules in that file, and shouldn't be. I guess it's too late to change, though. APA> We should probably have a xemacs-packages/README file APA> explaining this and advertising xemacs-packages/NEWS.packages APA> as well. Actually, we should have a Packages chapter in the Lispref. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."