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*. Stephen> That's what I meant. OK, but the stuff clipped here was putting symlinks in ~/.xemacs/. ms> You can also run side-by-side, but it's something I'm less and ms> less happy with. Stephen> What do you mean by "side-by-side"? You can have this directory structure xemacs/ <XEmacs in-place build tree> xemacs-packages/ mule-packages/ which XEmacs will recognize. It's something Ben requested a long time ago, but never bothered to defend once I'd implemented it and it started breaking folks' setups. ms> --package-path is almost always a bad idea, Stephen> "Almost always"?! In theory, maybe, but in practice --package-path Stephen> generally does exactly what the user wants: points to a specific Stephen> 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. Stephen> So are symlinks managed by hand. Ermh, no, they don't disable any part of the XEmacs logic for constructing the package path. There's some deep misunderstanding here, but I don't know what it is :-( ms> Could you (re-)describe what precisely you're asking for. I'm ms> thoroughly confused. Stephen> I just want XEmacs to conform to your Info documentation: Stephen> Such a directory containing a hierarchy is called a "root". Stephen> Whenever this section refers to a directory using the shorthand Stephen> `<root>', it means that XEmacs searches for it under all Stephen> hierarchies XEmacs was able to scrounge up. Stephen> Note the "all hierarchies." Note "[that] XEmacs was able to scrounge up." :-) Stephen> In other words, I want Stephen> cd $random-directory Stephen> tar xzf xemacs-21.5.10.tar.gz Stephen> ./configure Stephen> make Stephen> src/xemacs -vanilla Stephen> to find packages installed in $datadir/xemacs/xemacs-packages, unless Stephen> xemacs is configured --with-prefix=no. Erh, and this doesn't work now? That'd be a bug. Can you be more specific about the problem scenario? Stephen> This is what testers expect. This is what 21.4 does. If you don't Stephen> provide this, then testers will use --package-path. I did (I now use Stephen> EMACSPACKAGEPATH). And even with that fallback, you've still got the Stephen> problem that Linux distros now generally conform to the FHS, which Stephen> puts the package hierarchies under /usr/share/xemacs. They still need Stephen> --package-path. Any scenario which "needs" --package-path is just plain broken. I have every intention of fixing that: what exactly is that scenario? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla