Re: CVS after Ben merge - how is this *supposed* to work??

David> Umm, is that "version" as in xemacs-21.5 /vs/ xemacs-21.4, Yes. David> xemacs-21.4.6/i586-pc-win32 /vs/ David> xemacs-21.4.6/i686-pc-cygwin ? I would expect the former: David> my lisp is indeed under the release-specific directory but David> is shared between the two targets. You can do that, as you infer. I believe this "just works" by default, because the Lisp goes in the $prefix/lib/xemacs-$version/lisp directory, while platform-specific executables go in $prefix/bin and $prefix/lib/xemacs-$version/$arch. I don't know if this works for Windows, because ISTR the native Makefile varying from the *nix practice in a number of ways. David> Where? - just curious. It's only a minor quirk, but I David> don't see in what sense xemacs is a library. It's called the Filesystem Hierarchy Standard (FHS). Most Linux distros distribute it, so I don't know a canonical URL. David> This consistantly happens once I've done a package update David> -- when I first do the netinstall it is OK. This is not dumped Lisp, then. What I have seen happen is that package Lisp is placed in $prefix/xemacs/xemacs-packages/lisp/$package according to policy, but the list-packages interface will put new ones in $prefix/xemacs/lisp/$package for some reason. I haven't tracked this down, it only seems to happen to some people. The other possibility is that Mule packages are being placed into both xemacs-packages and mule-packages. But up to now you probably haven't been using Mule packages, right? Either way, use M-x list-load-path-shadows to find them. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.