>>>> "cgw" == Charles G Waldman
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
>>>> "APA" == Adrian Aichner
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."