Re: Recent changes to xemacs.mak

>>>>> "Ben" == Ben Wing <[email protected]> writes:

Ben> fut xemacs-design due to path questions below.  mike sperber take note!

Ben> Here we run into a sticky issue.  When you build into a different tree from the
Ben> source tree, and then try to run in place, you need some way of telling XEmacs
Ben> where the other half of its stuff is.  Unix does this through symlinks, but we
Ben> don't have them.  So I compiled the locations into the executable, but evidently
Ben> that leads to problems -- and furthermore, those values are not needed once we
Ben> install, but everything again ends up in one place.

Ben> So, possible solutions:

Ben> [1] For the portions of the build process that need to "run in
Ben> place" [everything that happens post-dumping], have the makefile
Ben> explicitly tell XEmacs where its other half is, through an
Ben> environment variable, command-line arg, etc.  Problem is that you
Ben> then can't do a test run in-place without specifying those same
Ben> values.  Developers often run in place, so ...

Ben> [2] Have a RUN_IN_PLACE option, which compiles the
Ben> above-mentioned values into the executable.  Then, either you can
Ben> run in place, or install, but not both.  Not so good.

Ben> [3] Have some sort of config file specifying where the other half
Ben> is.  Not copied by the install process.

Ben> [4] Maybe, XEmacs can detect whether it's running in an installed
Ben> directory structure or an in-place one, and then pay attention or
Ben> not to the compiled-in values.

Ben> [5] Some combination of the above.

XEmacs currently does [4] on Unix.  (The directory layout is
different, so it needs to know this.)

The easiest solution by far is probably to have an environment
variable EMACSSOURCE or something which points to the source
directory, and use that, when set, in in `paths-find-emacs-root'
instead of `executable_directory.'

I don't see a good way around telling XEmacs where the other half
is---you could compile the source directory in, but that's bound to
lead to spurious errors given past experience with our guessing magic
in the past.  Having to set an environment variable seems acceptable
to me, especially as you could do it from a script.

Note I'm in the midst of revamping the path searching code.  I'm only
temporarily stalled because of other work and deadlines.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla