Re: Recent changes to xemacs.mak

Mike Alexander <[email protected]>
Newsgroups gmane.emacs.xemacs.windows
Message-ID <601432671.1069779152@[172.27.6.114]>
I've been so busy with "real" work (or whatever passes for it) to do much with 
XEmacs lately.  I hope to get back to it soon.

Ben pointed out the correct way to set BUILD_DIR and SOURCE_DIR using 
$(MAKEROOT) so the first point is a non-issue.  The last point (the lib-src 
confusion) has been fixed so it's not an issue either.

That leaves the second point about how to make run in place work reliably on 
Windows where we don't have symlinks (which is how Unix deals with the 
problem).  Ben and Mike Sperber made a number of suggestions in follow up 
messages [1] and [2], but I don't think any of them has been implemented.  I 
think the consensus was that it was probably best to use an environment 
variable to help XEmacs run in place on Windows but I'm not exactly sure how 
that was to be done.

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


[1] <http://list-archive.xemacs.org/xemacs-nt/200303/msg00014.html>

[2] <http://list-archive.xemacs.org/xemacs-nt/200303/msg00015.html>

--On Sunday, November 23, 2003 6:32 PM +0100 Adrian Aichner <[email protected]> 
wrote:

>>>>>> "Mike" == Mike Alexander <[email protected]> writes:
>
> Hi Mike, what's up?
>
> I found stranded mail in my www.xemacs.org adrian mailbox.
>
> Have these issues been resolved?
>
> Best regards,
>
> Adrian

>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Mike Alexander                <mailto:[email protected]>
>> Arbortext, Inc.               +1-734-997-0200
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.