Re: [Q] Re: [PATCH] all my package fixes, mostly build-related

Stephen> This is more or less what Michael recommends. (He Stephen> actually has them in the build root for the core.) It is Stephen> not something that we can or should enforce, IMHO. ms> Ah, no, I've never recommended that. I've advocated symlinks ms> in the build directory for running *in place*. That's what I meant. ms> You can also run side-by-side, but it's something I'm less and ms> less happy with. What do you mean by "side-by-side"? ms> --package-path is almost always a bad idea, "Almost always"?! In theory, maybe, but in practice --package-path generally does exactly what the user wants: points to a specific Emacs root _where it already is and always has been_. ms> because it disables crucial parts of the XEmacs logic for ms> constructing the package path. Given that the package path is ms> a complex beast, this is asking for trouble. So are symlinks managed by hand. ms> Could you (re-)describe what precisely you're asking for. I'm ms> thoroughly confused. I just want XEmacs to conform to your Info documentation: Such a directory containing a hierarchy is called a "root". Whenever this section refers to a directory using the shorthand `<root>', it means that XEmacs searches for it under all hierarchies XEmacs was able to scrounge up. Note the "all hierarchies." [...] Moreover, XEmacs expects late hierarchies in the subdirectories `site-packages', `mule-packages', and `xemacs-packages' (in that order) of the `<root>/lib/xemacs' subdirectory of one of the installation hierarchies. In other words, I want cd $random-directory tar xzf xemacs-21.5.10.tar.gz ./configure make src/xemacs -vanilla to find packages installed in $datadir/xemacs/xemacs-packages, unless xemacs is configured --with-prefix=no. This is what testers expect. This is what 21.4 does. If you don't provide this, then testers will use --package-path. I did (I now use EMACSPACKAGEPATH). And even with that fallback, you've still got the problem that Linux distros now generally conform to the FHS, which puts the package hierarchies under /usr/share/xemacs. They still need --package-path. Admittedly, the documentation continues (If you run in-place, [the package hierarchies] are direct subdirectories of the build directory.) But I can't imagine anybody deducing that from the rest of the description. Nor that running in-place implies that the in-place xemacs _needs_ to have a whole set of private package hierarchies, and that running in-place "disables crucial parts of the XEmacs logic for constructing the package path." We know what that leads to. :-) -- Institute of Policy and Planning Sciences 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.