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

ms> Sorry, I'm not getting it. This discussion is about ms> *atypical* cases, namely about running in-place. (As have ms> most others been.) Things seem to work fine after "make ms> install." I am not sure this will be true on Windows, where the {bin,lib,share} hierarchies are nowhere near as ingrained as on Unixoid systems. Cf. Ben's installation, which (IMHO) _should not work_ without --package-path, since the parent of his generic "xemacs" directory is \src, not \lib or \share or Windows equivalent. (On Cygwin netinstaller installations, the root is "/Program Files/XEmacs", and it's otherwise conventional. I wouldn't be surprised if --with-prefix=no works there!) We regularly see Windows people reporting "I unpacked the SUMO like you said, but XEmacs _still_ doesn't find my packages." I suspect that's because they expect tar to work like setup.exe, and move the component into place. (And on a personal workstation, there's no particular reason why it shouldn't.) ms> I don't see how the introductory documentation can or should ms> address this issue. Then somebody else can write the docs. But definitely it's a FAQ, and the docs _should_ address it. And we need your help (cf my confusion about definition of "hierarchy" below). ms> I could add: "Construct the info path. This is the path where XEmacs will look for info files. ROOTS is a list of XEmacs roots. EARLY-PACKAGES is a list of early package hierarchies. LATE-PACKAGES is a list of late package hierarchies. 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. It _does_ add information. The facts that ROOTS are "XEmacs roots" and that *-PACKAGES are "hierarchies" (rather than, say, already computed search paths) helps. Not much, but it's better. But what would probably make that usable to "people-who-aren't-Mike" is "Construct the info path. This is the path where XEmacs will look for info files. ROOTS is a list of XEmacs roots, eg, as returned by `paths-find-emacs-roots'. EARLY-PACKAGES is a list of early package hierarchies. LATE-PACKAGES is a list of late package hierarchies. LAST-PACKAGES is a list of last package hierarchies. A \"package hierarchy\" is the top directory of a collection of installed XEmacs packages. It will be named \"xemacs-packages\", \"mule-packages\", or \"site-packages\", and will typically have subdirectories \"info\", \"etc\", \"lisp\", and \"pkginfo\". Package Info files are usually named for the package (eg, \"gnus.info\") or library (\"message.info\") and installed directly into the \"info\" subdirectory." For the load-path variant, you'd substitute "Package Lisp files are installed into a package-specific subdirectory of the \"lisp\" subdirectory (eg, \"lisp/xemacs-base\")." for the last sentence. Etc, etc. Or maybe a "package hierarchy" is a hierarchy whose root _contains_ "xemacs-packages" et al. Then you'd need to adjust the above for correct semantics of hierarchy. (This is why I haven't long since done something about this. Resolving questions like "what is a hierarchy?" requires analyzing the sources, as there is no clear documentation. So usually I just cut-and-try, and (locally) adopt what works, postponing public spirit for another day.... ms> I don't think there's a "typical value" for a root. ms> Specifically, the problems people are having crop up when it's ms> not /usr/local. The ones you're worried about, maybe. But I _am_ running with the package root (as far as the docs ever told me) in /usr/local, and I have (what I consider to be) problems. In man/xemacs/startup.texi, we should say something like "Typically, where XEmacs is installed by a distribution (eg, Red Hat Linux), the root for both the core XEmacs and the packages is /usr. Typically on Windows it is [whatever]. The default for locally built XEmacs is /usr/local, ie, $prefix. If the root is $ROOT, then the XEmacs executable and utilities like etags are in $ROOT/bin, version specific Lisp and other files are under $ROOT/lib/xemacs-$VERSION, and packaged Lisp is in $ROOT/lib/xemacs/xemacs-packages. (Mule packages go in $ROOT/lib/xemacs/mule-packages.) There are a number of variations and extensions to support specific XEmacs features and historical practice. However, if you can lay out your installation under a single ROOT as above, we recommend that. You are very unlikely to have any problems with that configuration. (For developers and testers: note that the XEmacs executable must be _installed_. The run-in-place case is much more delicate.)" The parenthetical remark will be unnecessary if we adopt the multiple roots implementation discussed elsewhere. (But that doesn't help Ben, because his /src won't be considered a root according to either criterion.) Ben> In my case, i have xemacs in-place in Ben> /src/xemacs/someworkspace/src/xemacs.exe, and my packages Ben> typically get installed into /src/xemacs/xemacs-packages, Ben> /src/xemacs/mule-packages, etc. AFAIK simply "--package-path=/src/xemacs" should work, at least it did for me. You might need "--package-path=~/.xemacs::/src/xemacs", I forget whether a null component overrides the defaults.[1] (*) I wonder if the package roots specified in --package-path should be considered before the computed roots, not substituted for them. (*) I don't see why --package-path=/src/xemacs/xemacs-packages should be allowed. (Maybe the option should be named --packages-roots or suchlike.) The *-packages names (plus site-modules and the deprecated site-lisp) are completely standardized. We shouldn't allow people to shoot themselves in the foot by omitting some of them, nor (as Ben points out) require them to be entered, since they're redundant. Footnotes: [1] To be precise, at the moment I have nothing in ~/.xemacs, and my packages are in /usr/local/lib/xemacs/{xemacs,mule,site}-packages. "EMACSPACKAGEPATH=/usr/local/lib/xemacs src/xemacs" does pick up the packages for me in 21.5. ISTR I used to set --package-path that way. -- 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.