Building AUCTeX from CVS [was: site-lisp not in load-path]

David> It seems that you have mostly taken a look at the source David> rather than the installation instructions. I did look at the installation instructions, but they don't serve my needs as a user (I normally _do_ build and keep package files for all XEmacs packages that I'm interested in, as opposed to just updating to the latest for completeness). Of course at the moment I'm wearing my developer's hat, as you realized, but I give several valid use cases for users below. David> That's not unusual for a configure/make installation. It is nowadays; most projects support installation to an empty $prefix, and almost as many support $DESTDIR. I don't think this is hard for AUCTeX to provide, it may even simply be a minor doc change: David> Either remove previous installations, or configure for a David> different target directory. That's insufficient, as I pointed out in my bug report. configure checks that you have a valid installation. You need --xemacs-packagedir to point to an existing directory, or for xemacs-packages to exist under $prefix. Not obvious from the installation instructions---they say that's sufficient, but it's not obvious it's necessary, and since XEmacs tools make no such check, XEmacs users are fairly likely to make the same mistake I did, I bet. I guess my suggestion is to make --with-xemacs-packages the flag for an XEmacs installation, and require that it point to an existing directory which should be xemacs-packages for a direct installation. --with-emacs would be allowed to point to xemacs, and could be used to specify a non-default xemacs (eg 21.5 vs 21.4). If --with-emacs points to XEmacs and --with-xemacs-packages is _not_ present, my preference would be to go ahead and try to install to site-lisp. But you seem to prefer to remove that option, which is OK as long as it's documented and --with-emacs=xemacs --without-xemacs-packages is a configure error. --with-xemacs-packages (no arg) would require that $prefix/lib/xemacs/xemacs-packages exist, and install there. ($datadir/xemacs/xemacs-packages doesn't work by default, XEmacs isn't FHS conformant yet, and $libdir/xemacs/xemacs-packages doesn't seem to be an appropriate thing to do since that violates FHS.) --with-xemacs-packages=existing-tmp-dir could be the undocumented way for a maintainer to install for a tarball, although it's probably better to have a separate option for that if you don't want users doing that. If you're going to use a separate option, it's a good idea to use the word "staging" in the name, as that will be familiar to XEmacs users who build from CVS. David> Please note that --without-packagedir requests to ignore David> the XEmacs package system and its structure completely. It David> might be saner to remove it completely. Sure. I was using it because I wanted to see what the layout and install process looked like for a generic Emacs install, but that's not your problem---it's easy enough for me to install Emacs. And it's acceptable to remove since (as the original thread shows) site-lisp is deprecated and may not even exist in typical XEmacs installations, while XEmacs modern enough to work with AUCTeX must have xemacs-packages to have enough functionality to make sense to use with AUCTeX. David> While this has not yet made it into the docs (as we just David> have started providing the XEmacs tarball), people are not David> supposed to build a separate package file for themselves, David> but rather are supposed to get a prebuilt package _if_ they David> want to have a standard package setup. It is quite David> pointless for people to build a package which will look David> just the same as a prebuilt package. Heh. Are you the same dak(a)gnu.org who was worrying about GPL violations because our XEmacs binary packages don't include the package build infrastructure a few months ago? Sarcasm aside, there are several valid use cases. (1) Rewinding to previous versions, which may be necessary for reasons completely out of AUCTeX's control. This is important for mission-critical packages, and for academics and other technical writers, AUCTeX surely is mission-critical. Eg, I haven't been screwed by XEmacs packages recently, but just yesterday I updated my libmysqlclient15 from Debian, it was broken, the breakage caused exim to think it was failing to deliver although in fact the mail was delivered, and I was embarrassed by a half-dozen unnecessary resends. But that was all, because I still had the previous, working .deb in my apt cache. dpkg -i and everybody's happy again. (2) Using a package tarball to install to multiple hosts. (3) Maybe I want CVS AUCTeX for a new feature, even though release is some weeks or months in the future. (4) Maybe my local AUCTeX is currently not identical to upstream, but I want to merge upstream improvements. This is free software we're talking about. Why build from CVS in cases (1) and (2)? Any number of reasons: byte compiler improvements not backported to the stable version, different optimization level (yes, XEmacs has optional optimizations), etc. And some people just insist on building things themselves. IMO you want to make those people as happy as possible because they're the kind of users that turn into developers. David> Building and installing AUCTeX from sources is not a David> problem. It currently _is_ a problem if you don't believe in overwriting a working installation without backup, at least until the instructions make clear how to install to a different place which may not even exist yet. ("Use mkdir, dummy" is an acceptable response.) If you have package tarballs, it's as easy as cat pkginfo/auctex.MANIFEST | xargs rm -f tar xzf $BKUP_PKGS/auctex-$WORKING_VERSION-pkg.tar.gz If you don't, it's quite a bit hairier, unless you keep careful records of what worked, and can cvs update to an appropriate revision. Even then that's substantially more work and tedium. David> It is not clear that it would be beneficial for users to David> build a package file with the same name as our official David> XEmacs binary package but possibly different contents. I'd David> rather install the thing right into the package tree David> without making it a separate file. I agree with your suspicions about the package file name; we've needed to do something about the bogus naming scheme for quite a while. But we have differing opinions about the desirability of installing directly into the tree. True, for _most_ users that is precisely what they're going to do, and it's probably even the best thing for them unless they're really really paranoid. But for many users that is not going to be close to optimal. And I suspect those are going to be the kind of users you want to be as happy as possible with everything about AUCTeX, not limited to advertised functionality. IMHO YMMV, etc. David> still leaves the question of how one can with the least David> amount of effort import the stuff into the XEmacs package David> repository. The current procedures require far too much David> manual labor, given that we essentially start with a viable David> end product already. Just what do you think I thought I was doing? :-) I really think the right way to go is my "opaque-packages" proposal. The layout you've designed for AUCTeX in Emacs really makes much more sense than the one we currently demand, which is oriented to a large collection of small but interdependent packages. AUCTeX has few, if any, external dependencies on LISP packages, and I would suppose is rarely required by other packages. There's no reason not to provide a few autoloaded entry points and otherwise let AUCTeX find its internal APIs itself. This doesn't have pui support yet, but that won't be that hard to provide, and "cd /path/to/xemacs-packages; tar xzf auctex-pkg.tar.gz" is hardly burdensome as a transition strategy. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.