Re: Find architecture-specific directories correctly

me> Question: why are we setting module-load-path at _dump_ time? I still wanna know. I'd rip it out and test it, but I don't use any modules so I don't think that test would have any meaning. This is really a design decision at this stage of the game. AFAICT, what ripping that out means is that you cannot _load_ a module within the dump process, although you can _dump_ code that will load modules once the top level loop gets started (since that's after startup.el does it's thing). me> This path[sic] duplicates the module-load-path initialization me> from dump-paths (which is run early at dump-time only AFAICT), me> to startup.el (which is run later both at dump-time and at me> run-time). Not tested, I'm working across a slow modem, and me> it's bedtime. Will test tomorrow, but I thought I'd let you me> know what I found. me> Index: lisp/startup.el me> =================================================================== me> RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/startup.el,v etc etc. OK, I've tested it pretty thoroughly. That patch gives consistent behavior, installed or run-in-place, build-in-source or with --srcdir, and in the case of --srcdir, whether or not there is an existing build or just pristine source in $srcdir. But: With this patch, and Jerry's improved Dec. 20 patch, it does _not_ detect the run-in-place sibling modules directory. This seems to be incorrect behavior to me. (I don't know how to fix it offhand.) -- 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."