Re: CVS problems: how to put xemacs-20 and xemacs-packages together?

[Jareth, are you back? This response might be useful to put up for developers until something more formal gets written.] Joerg Plate <plate(a)psyche.kn-bremen.de&gt; writes in xemacs-beta(a)xemacs.org: The `xemacs-packages' lisp source hierarchy is not intended to be run from. This is a deliberate feature and allows the maintainer/installer to keep multiple incompatible versions of packages around. There are two such in my tree right now -- Pterodactyl Gnus & Gnus 5.6 and VC & VC with clearcase. Another thing to remember is that XEmacs 19 & 20 are bludgeons -- you get hammered with everything whether you want it or not. The current structure is set up to allow the builder to tune to a fairly[1] fine degree what lisp gets installed. As noted below, I only run with about 56% of the total XEmacs packages installed and I enjoy the leaner XEmacs. Before you go any further, make sure you have a full complement of GNU tools. You will need at a minimum GNU make, GNU tar and GNU cp. GNU cp is only needed if you don't have a system cp that preserves timestamps when copying. To bootstrap yourself you only need one package installed -- mule-base. You don't need mule-base if you're not building with Mule. Grab the mule-base binary package tarball from ftp.xemacs.org, create a directory called `mule-packages' in the toplevel XEmacs core source directory and install mule-base there. Configure the XEmacs core as you wish and build but don't `make install'[2]. To build the rest of the XEmacs packages, go into the toplevel xemacs-packages directory and edit XEmacs.rules to fit your installation. You will need to adjust the `XEMACS =' assignment to point to the run-in-place binary you built in the previous step. Comment out the `BUILD_MULE=t' assignment if you're not building with Mule. Note that `PKGDIR' is currently ignored[3]. If you're brave[4], change the `STAGING =' assignment to point to where you are going to install the XEmacs packages. You will install them somewhere based on how you set $prefix when configuring XEmacs. The default is /usr/local, in which case packages get installed in /usr/local/lib/xemacs/xemacs-packages and /usr/local/lib/xemacs/mule-packages. After editing XEmacs.rules, type `make bindist' and let it churn. Depending on the speed of the machine you're building on, this may take awhile. After this is done, create the xemacs-packages and mule-packages directories in $prefix/lib/xemacs and install the -pkg.tar.gz files of the packages you wish to have at run-time. I only install 45 of the 81 available packages for my own use, so don't feel compelled to install everything. If you're installing into an empty directory, a straight `tar zxf' will work. If you're installing into an already populated directory you should always delete the previous version of a package before installing a new one. From the command line: $ rm `cat pkginfo/MANIFEST.${PACKAGE}` where ${PACKAGE} is the name of the package you are installing, will suffice to get rid of the previous version. If you are running with an old package tree that doesn't have the pkginfo directory, $ rm -rf lisp/${PACKAGE} etc/${PACKAGE} should work too. Lisp files get moved and seeing shadowed files at the next XEmacs dump is a sure sign you missed deleting an obsoleted lisp file that got moved to another package. Footnotes: [1] When single-file packages are implemented, you will be able to further tune what lisp files get installed. [2] Well, go ahead and `make install' if you really wish to. It doesn't really matter. I find it easier to run the binary in place during development and only run `make install' on final versions. [3] Now that a safe package delete exists, it will be straightforward to implement a straight `make install' that bypasses tarball generation. [4] And not building with Mule.