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

Excessive CC list trimmed. ms> Note I said "introductory documentation." I'll be happy to ms> document it somewhere else. Once it's settled down, that is. OK. ms> But then this part of the documentation would be duplicated ms> many, many times throughout the code. Besides, the knowledge ms> here is encoded in some other, common abstraction. (This ms> would be a case of comment duplication which is about as bad ms> as the corresponding code duplication.) Agreed. I didn't mean that as a patch. ms> If [--package-path splices into the computed hierarchies ms> rather than replacing them], it should be configurable where ms> the system paths occur. Which means more syntax, more ms> documentation, more complication. I'd rather punt on this ms> one. OK, I see your point. --package-path freezes the hierarchies, and therefore is a last resort. Stephen> (*) I don't see why Stephen> --package-path=/src/xemacs/xemacs-packages should be Stephen> allowed. (Maybe the option should be named Stephen> --packages-roots or suchlike.) The *-packages names Stephen> (plus site-modules and the deprecated site-lisp) are Stephen> completely standardized. We shouldn't allow people to Stephen> shoot themselves in the foot by omitting some of them, Stephen> nor (as Ben points out) require them to be entered, since Stephen> they're redundant. ms> Are you suggesting we should do a sanity check based purely on ms> the name of the directory? I think this would make things ms> more opaque. We could check the contents, but they might not ms> be there yet :-( I don't think there should be _any_ sanity check (except for the colon syntax) on --package-path. Use of it is an admission on the admin's part that his system is insane and he can't or won't reconfigure it. How are we supposed to guess what kind of insanity XEmacs is supposed to conform to? If the contents aren't there yet, then any package-dependent build operations (there are some in "make check") will fail. Currently those are all benign; let's keep it that way. And it's the admin's duty to avoid user/runtime problems by installing packages where he claims they will be. However, the above all depends on having some reasonable default for a package root. Otherwise people will question _our_ sanity, not the nonconformist admin's. On Linux, Cygwin, Depot systems, /opt/$package systems, and probably *BSD and native Windows, at least, we have such a beast: $datadir/xemacs. -- 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.