Re: load cvs-status requires mule

cgw> I suspect that the binary-kit packages must have somehow cgw> gotten infected with Mule; I think it has to do with how they cgw> were built, rather than the pcl-cvs code itself, which has no cgw> Mule dependencies. No direct dependencies. But it requires lots of stuff, such as cl.el, which requires cl-macs.el, which has a rather interesting hack that seems to require a random feature (= (car features)) from the emacs that loads it. This maybe then gets compiled into the binaries. The feature that gets required _should_ be a 'cl-xxx, I think, but I don't know how to check that. If in fact it can be 'mule, and this is the source of the spurious require, anything that uses cl.el could suffer from the same problem. And you really have to trace _all_ the requires and autoloads. (Somebody started to write a script to do all that tracing at one time. Do I recall ... ?) cgw> Oops, just after writing that last sentence I did a "grep cgw> mule pcl-cvs/*el" and came up with this: cgw> ;; chars sets. Ripped from cvstree cgw> (defvar cvstree-dstr-2byte-ready cgw> (when (featurep 'mule) cgw> in cvs-status.el... this is the only reference to Mule in cgw> the entire pcl-cvs package. Is this possibly the source of cgw> the problem? I don't see how it could be, it's explicitly conditioning on the presence of Mule, which is known to required for lots of code to work at all. APA> When should they be BUILD_WITHOUT_MULE = t ? All that BUILD_WITHOUT_MULE = t does is inhibit building the packages in the subdirectory mule AFAIK, to prevent a no-mule xemacs from choking on the stuff in there. I don't see how this would make a difference to what gets require'd by compiled packages. -- 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."