* Matthieu Moy <[EMAIL PROTECTED]> writes: > Steve Youngs <[EMAIL PROTECTED]> writes: >> * lisp/xtlahack.el: New.
> I still don't understand why we should need one more file for the > build system. xtla-xemacs.el is where XEmacs problems should be > managed, I don't see the need for another file now. (Maybe there is, > but you didn't convince me yet) xtla-xemacs.el is (should be) for XEmacs specific run-time issues (I imagine that xtla-emacs.el serves a similar purpose for GNU/Emacs). Whereas, xtlahack.el is for compile-time issues regardless of Emacs flavour. For XEmacs builds we're using a very clean environment, -no-autoloads means: no init file, no site file, nothing autoloaded (ie, as bare-bones as it comes). Using xtlahack.el, which is loaded with each XEmacs instance during the compile (except for auto-autoloads.el and custom-load.el), means we can hand pick our build environment and greatly reduce the number of "surprises". Yes, the stuff in xtlahack.el could be split up and put into xtla-(x)emacs.el, wrapping it in `(eval-when-compile...)' and `(require..)'ing it wherever it's needed. Good luck with sorting out the cross-dependency problems that's likely to cause. Alternatively, instead of require'ing it you could load it for every (X)Emacs instance, the same way xtlahack.el is intended to be used. But how do you stop the stuff outside of the `eval-when-compile' from loading? Sure, that probably won't matter all that much, but it sure is sloppy. > I had done the moved the code of xtlahack.el to xtla-xemacs.el, > and you re-added it, so, the code is now duplicated. Maybe this is my bad, but you made absolutely no mention of this in your patch-log, so how on earth was I to even suspect that it was done? From the cryptic clues I got from `tla cat-log patch-nnn' I guessed that you had simply reverted the majority of my patch. > I've committed another patch removing xtlahack.el, and added the > necessary `autoload' to xtla-defs.el. I've now tested it with a more > recent version of XEmacs, I managed to reproduce your problem and to > fix it. Well if you're talking about... [EMAIL PROTECTED] ...it's not fixed. xtla-core.el and xtla-xemacs.el fail to build. Also, there are still quite a number of "undefined function" warnings (I had gotten rid of _all_ of those). My fix was complete, simple, kept everything in one place, easily extensible for future changes to xtla, and both XEmacs _and_ GNU/Emacs could take advantage of it. Yours, OTOH, seems to be still only half a fix, spread across multiple places, and the next time a problem like this crops up the "fixing" process has to begin all over again from scratch (with mine you can skip several steps of that process because you know you're going to edit xtlahack.el :-P). Therefore, I strongly suggest that you revert your "fix" and replay my patch-4. > 'Hope everybody's happy now ;-) Nearly. :-) I'm looking forward to getting the build in shape so I can start fixing real problems in the code. And when xtla is running well enough on XEmacs I want to talk to you about having it included as an "official" XEmacs package. :-) BTW, there's no need to Cc me on anything to this list, I'm subscribed. :-) -- |---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---| | Te audire no possum. | | Musa sapientum fixa est in aure. | |----------------------------------<[EMAIL PROTECTED]>---|
pgpnrS3kqLwkB.pgp
Description: PGP signature
