Mail Archives: djgpp-workers/2001/03/04/06:39:14
On Sun, 4 Mar 2001, Tim Van Holder wrote:
> > Also, I don't understand the ``outdated'' part. The binary on SimTel
> > is based on the latest official release of Emacs.
> My mistake - I should have checked. I thought there had been no release
> of 20.7
The port is called "20.5", but it includes all the bugfixes which went
into 20.6 and 20.7 that are relevant to DJGPP. There are only a couple
of these bugfixes, anyway.
> > I don't plan to change the Emacs installation tree. The DJGPP port is
> > set up to build and install in-place. If you move it, you will have
> > to set all kinds of environment variables to let Emacs find its files,
> > or hack the epaths.h header to have the relevant directories
> > hard-wired there, in which case they will not work on someone else's
> > machine.
> Odd - I built emacs 20.7 from the regular configure, with
> prefix=/dev/env/DJDIR.
That's not how Emacs is configured and built for DJGPP. It uses its own
config.bat and a set of scripts to edit Makefile.in's into Makefile's.
> This worked fine; and I've now moved my DJGPP
> tree to a different drive and emacs still works fine.
There are several problems with this:
- Emacs is one of the few ported packages that are supposed to work even
without a full DJGPP installation, because it's very useful even to
people who don't want to develop programs. (That's why the binary
distro includes the emulator and CWSDPMI.) A binary configured with
--prefix=/dev/env/DJDIR will not work without DJGPP.ENV.
- By configuring Emacs with the original configure script you get a
different binary, because the set of library functions detected by
configure is different from what the msdos/sed*.inp scripts produce.
This is significant since Emacs imposes special requirements on the
library functions it calls. In particular, any library function that
calls malloc might mess up Emacs if that library function accepts a
pointer to buffer text, because Emacs sometimes relocates buffers
when malloc is called. The sed*.inp scripts take care to put into
the generated config.h only functions which were scrutinized to be
Emacs-safe. When you use the configure script, you are on your own.
- Emacs has traditionally required only a minimal set of non-standard
tools to be built, again because it is such an important and basic
tool. Asking people to install Bash, File-, Text-, and Sh-utils,
Grep, and whatsnot is a far cry from this tradition. If the official
Emacs build procedur ever moves towards full Autoconf'iscation,
including libtool, depcomp, and other atrocities, it is possible that
we won't have any choice but switch to using configure. But until
and unless that happens, I don't see why we should throw the current
well-tested and proven setup out the window.
> I did some other tweaking here and there (too
> long ago to remember), but IIRC there was no major work involved.
The question is: how general was that tweaking? If you needed to tweak
Emacs to the specifics of your system, that's no good. But since you
don't remember, I guess we'll never know.
Another question is did you try all the targets in the various Makefile's
which normally users don't run. Makefile's in the leim/, lisp/, and
man/ directories are of particular importance, as well as "make TAGS".
They should all work, or else people will not be able to develop Emacs.
> Given that emacs can find its files just fine if put in $DJDIR/bin and
> $DJDIR/share/emacs, I didn't see a real reason to banish it to
> $DJDIR/gnu/emacs, except perhaps that building in-place does not require
> having enough space for two lisp trees; then again, there is no reason
> why you should keep the source tree around after a 'make install'.
Did you actually try to remove the sources? Did it still work?
The thing is, there are lots of subtle tricks in the DJGPP port that are
meant to prevent complications from happening, due to missing directories,
missing environment variables, etc. Many of these tricks rely on the fact
that Emacs is built in-place and run from the same tree where it was
built (albeit with some of the directories, such as src/, removed). It
doesn't make sense to redo all that work, some of which goes back to
1991-1994, when Manabu Higashida and Morten Welinder made the initial
port, unless we have a very good reason.
- Raw text -