Re: Core Dump on make install latest 21.2 from CVS

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org&gt; writes: >>>>> "Moiself" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de&gt; writes: Moiself> OK, I can see that. I hate the fact, however, that mule/ lives under Moiself> lisp/ --- it's not a true reflection of the dependencies here. It Moiself> would be much more natural, IMHO, to have a mule-lisp/ directory Moiself> alongside lisp/. My objection to this remains. I still think it's the wrong direction to go in. Martin> Actually, I think that might be moving in the wrong direction. I Martin> don't like how mule is singled out for being odd, for examples in Martin> makefiles. I'd like to have no special treatment for mule files. Martin> lisp/ Martin> lisp/mule Martin> lisp/ldap Martin> lisp/C-LEVEL-FEATURE Martin> where perhaps the directory lisp/C-LEVEL-FEATURE is only added to Martin> load-path when FEATURE is available. MS> Well, I think coupling filename syntax with symbol syntax even more MS> tightly in this manner is a really bad idea. It would make more sense MS> to add some metainformation to those directories. (My package MS> redesign draft has provisions for this.) (I wasn't suggesting that the name of the directory was automatically compared to the name of a feature) MS> Note that we're talking about Core Lisp here, not packages, and that, MS> as Stephen pointed out, Mule is different from the rest. Presently, MS> we're also not just talking about simple feature availability here: a MS> Mule XEmacs is an entirely different beast from a non-Mule one. I don't think Mule and non-Mule xemacs are _so_ intrinsically different. For example, it might very well be possible to teach non-mule xemacs how to byte-compile mule elc's, or at least to recognize when it cannot do so. But yes, it's a big job.