Re: Recent changes to xemacs.mak

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

----- Original Message -----
From: "Mike Alexander" <[email protected]>
To: "XEmacs NT List" <[email protected]>
Cc: "Ben Wing" <[email protected]>
Sent: Monday, March 03, 2003 10:31 PM
Subject: Recent changes to xemacs.mak


> I like the new support for multiple build trees from a single source tree
> on Windows.  I've had a kluge like that for ages, but Ben's version is much
> better.
>
> I have noticed a couple of things that aren't quite right, or at least are
> a bit confusing.  For one thing, relative paths for BUILD_DIR or SOURCE_DIR
> don't work right.  I've been using "..\Debug" and "..\Release" to build
> both a debug and release build from the same source tree and had to change
> the make file a bit to always cd back to the original directory after each
> cd somewhere else so subsequent file references or cd's based on BLDROOT or
> SRCROOT work right.  I can submit a patch for that if it's necessary.

Instead of kludging around this, the solution is just to not use relative paths.
Instead,
use paths based off of $(MAKEROOT),  which is the root of the tree you're
running make
from -- i.e. one level up from where xemacs.mak is located.  I put a note in
config.inc.samp to this effect.

>
> I also got in to trouble when I built a copy of XEmacs using the "install"
> target on one machine then copied the resulting install tree to another
> machine.  It happened that the second machine had an old copy of the build
> tree on it.  Because xemacs.mak defines PATH_LOADSEARCH and PATH_DATA if
> SEPARATE_BUILD is true, the copy on the second machine started using lisp
> files from the old build tree.  It got itself very confused when it used a
> version of cus-face.el from last September.  I'm not quite sure what the
> best fix for this is since I'm not really sure why xemacs.mak defines
> PATH_LOADSEARCH and PATH_DATA.  I fixed it easily enough by renaming the
> build tree on the second machine, but this could hit someone else someday.

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

So, possible solutions:

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

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

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

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

[5] Some combination of the above.

What do you think?

>
> One other thing is that XEmacs seems to think that the DOC file should be
> in $(INSTALL_DIR)\lib-src but the install target puts it in
> $(INSTALL_DIR)\$(EMACS_CONFIGURATION).  In fact the install target doesn't
> create lib-src at all and XEmacs complains about the install tree if it
> doesn't exist.

hmm, i'll look into this.

>
> Mike Alexander                <mailto:[email protected]>
> Arbortext, Inc.               +1-734-997-0200
>