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

ms> I don't see how the introductory documentation can or should ms> address this issue. Stephen> Then somebody else can write the docs. But definitely it's a FAQ, and Stephen> the docs _should_ address it. And we need your help (cf my Stephen> confusion about definition of "hierarchy" below). Note I said "introductory documentation." I'll be happy to document it somewhere else. Once it's settled down, that is. ms> I could add: Stephen> "Construct the info path. Stephen> This is the path where XEmacs will look for info files. Stephen> ROOTS is a list of XEmacs roots. Stephen> EARLY-PACKAGES is a list of early package hierarchies. Stephen> LATE-PACKAGES is a list of late package hierarchies. Stephen> LAST-PACKAGES is a list of last package hierarchies." ms> But this adds verbosity, not information. You say you're ms> confused, but you don't state a question that you think isn't ms> answered. Stephen> It _does_ add information. The facts that ROOTS are "XEmacs roots" and Stephen> that *-PACKAGES are "hierarchies" (rather than, say, already computed Stephen> search paths) helps. Not much, but it's better. OK, I see, but that for me means that the variables are poorly named. I hope to address this. Stephen> But what would probably make that usable to "people-who-aren't-Mike" is Stephen> A \"package hierarchy\" is the top directory of a collection of Stephen> installed XEmacs packages. It will be named \"xemacs-packages\", Stephen> \"mule-packages\", or \"site-packages\", and will typically have Stephen> subdirectories \"info\", \"etc\", \"lisp\", and \"pkginfo\". Package Stephen> Info files are usually named for the package (eg, \"gnus.info\") or Stephen> library (\"message.info\") and installed directly into the \"info\" Stephen> subdirectory." But then this part of the documentation would be duplicated many, many times throughout the code. Besides, the knowledge here is encoded in some other, common abstraction. (This would be a case of comment duplication which is about as bad as the corresponding code duplication.) Stephen> The ones you're worried about, maybe. But I _am_ running with the Stephen> package root (as far as the docs ever told me) in /usr/local, and I Stephen> have (what I consider to be) problems. Right. We need to fix the code and then update the docs accordingly. Stephen> In man/xemacs/startup.texi, we should say something like Stephen> "Typically, where XEmacs is installed by a distribution (eg, Red Hat Stephen> Linux), the root for both the core XEmacs and the packages is /usr. Stephen> Typically on Windows it is [whatever]. The default for locally built Stephen> XEmacs is /usr/local, ie, $prefix. If the root is $ROOT, then the Stephen> XEmacs executable and utilities like etags are in $ROOT/bin, version Stephen> specific Lisp and other files are under $ROOT/lib/xemacs-$VERSION, Stephen> and packaged Lisp is in $ROOT/lib/xemacs/xemacs-packages. (Mule Stephen> packages go in $ROOT/lib/xemacs/mule-packages.) Stephen> There are a number of variations and extensions to support specific Stephen> XEmacs features and historical practice. However, if you can lay out Stephen> your installation under a single ROOT as above, we recommend that. Stephen> You are very unlikely to have any problems with that configuration. Stephen> (For developers and testers: note that the XEmacs executable must be Stephen> _installed_. The run-in-place case is much more delicate.)" Sounds good to me. Stephen> AFAIK simply "--package-path=/src/xemacs" should work, at least it Stephen> did for me. You might need "--package-path=~/.xemacs::/src/xemacs", Stephen> I forget whether a null component overrides the defaults.[1] Stephen> (*) I wonder if the package roots specified in --package-path should Stephen> be considered before the computed roots, not substituted for them. If at all, it should be configurable where the system paths occur. Which means more syntax, more documentation, more complication. I'd rather punt on this one. Stephen> (*) I don't see why --package-path=/src/xemacs/xemacs-packages should Stephen> be allowed. (Maybe the option should be named --packages-roots or Stephen> suchlike.) The *-packages names (plus site-modules and the deprecated Stephen> site-lisp) are completely standardized. We shouldn't allow people to Stephen> shoot themselves in the foot by omitting some of them, nor (as Ben Stephen> points out) require them to be entered, since they're redundant. Are you suggesting we should do a sanity check based purely on the name of the directory? I think this would make things more opaque. We could check the contents, but they might not be there yet :-( BTW, this kind of discussion is *exactly* the reason why I dislike --package-path: too many semantic issues and too many ways to shoot yourself in the foot. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla