Re: One more time, why can't xemacs-packages be a sibling of xemacs?

Stephen> This, er, doesn't seem to be documented anywhere. info Stephen> xemacs 'startup paths' says "If you run in-place, these Stephen> [hierarchies] are direct subdirectories of the build Stephen> directory." ms> Correct, I haven't gotten around to that, mainly because I ms> expected there'd be dust in its wake that would need settling. ms> The proof is here. Stephen> What is it that Ben wanted? ms> Actually, I am not sure anymore. OK, well, I'll be happy to help with documenting (even if you want me to just go RTFSource) as long as I have access to rationales. I posted because the source gave me no real idea what the rationale was.... Stephen> Is this just so that Windows users can put their Stephen> installed package hierarchy in c:\xemacs-packages and Stephen> their sources in c:\xemacs or something like that? ms> That's how I read him originally. I think that's bad policy (people building from source should be able to handle hierarchical directory structures and the difference between installed applications and running-in-place), but I'm open to counterargument. I don't use Windows, so I have no right to a strong opinion about how Windows users should do things. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."