BTW, I forgot to say before: "Congratulations and thanks!" to you and Mats for persevering through this. Uwe Brauer writes: Fine. Then the distributed packages are expected to run properly no matter what the user's TeX installation looks like (as long as LaTeX is on $PATH)? No, that's Bourne shell. I don't use csh at all. You need to do "something of the sort," I think. Specifically, cvs wants you to rm the file before doing cvs remove. You need to substitute "rm {} && cvs remove {}" for the simple "cvs remove {}". The most important thing is preserving the XEmacs meta-data (Makefile, package-info-in), as David K points out. I was worried that (eg) rm package-info.in cvs remove package-info.in cp ../new/package-info.in package-info.in cvs add package-info.in would disconnect the file's history, but actually if you cvs remove then cvs add a file, the old file,v is recovered from the Attic, so you don't lose any history (you just get the spurious cvs remove/add pair, but that's no big deal). Please do 'cvs tag' before and after this operation, though. That way (a) if something really bad happens, you can recover pre-sync state, and (b) post-sync diffs can be against something more or less similar to current state. Well, it's *your* XEmacs package. Do what makes sense for you. Just do what you need to do, and coordinate with Norbert so that he can make any recent packages before your change. Then we'll have a big auctex-building party and deal with any issues that come up. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats Lidell writes: I've already heard from one reviewer worrying about the hacky aspects. But we don't actually have a patch to review. The few lines in XEmacs.rules are not a big deal, and figuring out a better way to do what's necessary for AUCTeX requires knowing what gets done. The worst that can happen IMO is that Norbert will have to set the set of xemacs-packages to build to "everything but AUCTeX" until problems get worked out. Somewhat more distressing to you but quite convenient for him, Norbert could just revert the whole commit. :-) So I don't think it's anything to worry about too much. My opinion (as a single reviewer, I haven't consulted with anybody) is that you should just go and ask Norbert when it would be convenient for him for you to commit what you've got (he'll probably say "now" :-), and we can go from there. It would be better to be more specific. If you can't easily describe it in words, something like "See AUCTeX's XEmacs Makefile ca. line XXX" is sufficient. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Uwe Brauer <oub(a)mat.ucm.es&gt; writes: If there is a problem with stuff being appended to an autoloads file manually, it is conceivable that the AUCTeX build procedure might be changed to process the respective stuff into autoload cookies in some temporary file from which the normal autoload generation could pick them up. But you'll need to describe the exact problem and the approach you'd like to be taken to the AUCTeX developer list. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> Is there a reason why this needs to be done? I'm not Stephen> unalterably opposed to it, but most of the trouble seems to Stephen> be caused by lazy programming enabled by autoload abuse. I have tried to come up with a method to generate the auto-autoloads.el so that the result will be very close to what the auctex team delivers in their xemacs package. I hope that this will make it easier to support auctex within the XEmacs Packages because there will be less differences between the packages. I don't think we need to fix the auto-autoloads problem now. If we try to do that it will delay this issue even further. To come up with a less hacky solution I have tried an approach where the autoloads rules are made optional in XEmacs.rules. The rules are then implemented in the package Makefile where the package is free to do what it likes. The patch is simple: ---------------------------------------------------------------------- Index: XEmacs.rules =================================================================== RCS file: /pack/xemacscvs/XEmacs/packages/XEmacs.rules,v retrieving revision 1.59 diff -u -r1.59 XEmacs.rules --- XEmacs.rules 24 May 2007 20:22:29 -0000 1.59 +++ XEmacs.rules 15 Feb 2008 23:28:00 -0000 ＠＠ -458,6 +458,7 ＠＠ GENERATED_ELC_DEPENDENCIES = $(ELCS:.elc=.el) $(ELCS_1:.elc=.el) \ $(AUTOLOAD_PATH)/_pkg.el +ifneq ($(PACKAGE_HANDLES_AUTOLOADES),t) # If Makefile or _pkg.el has changed (Makefile will trigger _pkg.el # rebuilding), then our suppress forms may have changed. Just rebuilding # the autoload file normally isn't enough as the old suppress forms will ＠＠ -491,6 +492,7 ＠＠ -l autoload -f batch-update-autoloads $^ ＠touch $(AUTOLOAD_PATH)/auto-autoloads.el ＠rm -f $(AUTOLOAD_PATH)/auto-autoloads.el~ +endif endif $(AUTOLOAD_PATH)/custom-load.el : $(GENERATED_ELC_DEPENDENCIES) ---------------------------------------------------------------------- By defining the macro PACKAGE_HANDLES_AUTOLOADES=t before including XEmacs.rules the package can disable the auto-autoloads-rules and use its own rules. It is easy to revert this once the auctex build procedure doesn't depend on cooking a special auto-autoloads.el. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats Lidell writes: I think the best thing at this point is to just get the whole thing into CVS where people and the Package Build Smoketest can easily look at it. As long as you CVS tag the current state, it's trivial to recover by reverting the changes. Norbert, what do you think? Do you plan to release a SUMO soon, or anything else that would be held up by a broken AUCTeX? Mats's XEmacs.Rules patch is small and easy to revert, and I can't help document it until I see how it's used. We could also put both on a CVS branch. I don't want to mess with a megapatch in this case because it involves lots of removed, moved, and added files. diff(1) and patch(1) don't deal with them any better than CVS does, and we *have* to fix CVS anyway.... _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen J. Turnbull writes: Well the idea is simple. Auctex needs an additional rule for auto-autoloads.el. It is used for appending more info into the file. So the double colon rules for auto-autoloads.el must thus all have the same dependencies so that they all are executed (or a smarter way than simply appending the addition is needed.) (Which in fact could be an alternative way to solve this.) Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> Well, that's obvious. What is not obvious at all is why the Stephen> additional rule is needed -- you yourself admit there may be Stephen> better ways to accomplish the task -- and understanding that Stephen> requires showing us the AUCTeX patch as well as the Stephen> XEmacs.rules patch. The XEmacs.rules patch has been put on display before. Here comes an excerpt from the auctex Makefile, slightlty modified by removing some lines not relevant to this, shows how it is used in the package: ---------------------------------------------------------------------- EXTRA_AUTOLOADS_DEPENDENCIES = tex-site.el preview/auto.el [...] include ../../XEmacs.rules $(AUTOLOAD_PATH)/auto-autoloads.el:: $(EXTRA_AUTOLOADS_DEPENDENCIES) cat tex-site.el >> $(AUTOLOAD_PATH)/auto-autoloads.el cat preview/auto.el >> $(AUTOLOAD_PATH)/auto-autoloads.el ---------------------------------------------------------------------- Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta