Mail Archives: djgpp-workers/2001/03/04/13:04:25
> From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
> Date: Sun, 4 Mar 2001 17:50:51 +0100
>
> > - 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.
> Actually, it probably will if the user sets DJDIR=x:/path/to/emacs/install.
It should be able to work with no environment variables at all.
> Anyway, I think emacs figures this out at startup or dump time.
No, it doesn't. The default directories come from src/epaths.h, which
is generated at configure time.
> In the
> latter case, you could distribute an impure binary, and supply a simple
> batch file to dump emacs after installing (even easier with a zippo
> package). This would even allow people to dump additional packages into
> emacs (or disable some).
I don't think this is a practical alternative: dumping Emacs is not
for the faint at heart. One corrupted .elc file, and you are toast.
> As I found out when reading the diffs, I added an additional PATH_*
> define to emacs (PATH_INSTALLATION). Emacs will use this to locate
> its support files if it can't find out by itself.
Right, that's exactly one of the reasons Emacs in its DJGPP port has
all the directories locatable relative to its binary.
But adding another environment variable is IMHO not a good idea,
because it goes against the way Emacs works on Unix. Instead, Emacs
should be able to use the existing variables, such as EMACSDATA, and
define them automatically so that they point to the right places,
given argv[0] as the starting point.
> > - 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.
> IMHO it is just as easy to add the necessary #undef's to s/msdos.h.
s/msdos.h is not for this stuff, it's for system-dependent definitions
that usually don't change. By contrast, the list of HAVE_*
definitions in config.h tends to change with every release.
> I didn't consider this point though; is there a list of such functions, or
> should I just look through the sed scripts?
See msdos/sed2.inp. (Make sure you only look at the part that is
relevant for DJGPP v2.x.) It makes config.h include <sys/config.h>
from djdev, so look there as well.
> > - 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.
> This is a good point. But many emacs packages also use these tools (I can't
> think what I'd do without (M-x) grep, for example).
These additional packages are not required for editing. Instead of
"M-x grep" you could use "M-x occur".
> * src/emacs.c
> Default Vinstallation_directory to Qnil on non-MSDOS systems.
Doesn't this break "C-h i" if you remove INFOPATH from the environment
and/or DJGPP.ENV?
> Add DJGPP-specific undumping commands:
> go32 temacs -batch -l loadup dump
I think this would waste 512K (the stale stack from temacs) in the
dumped executable. How large is emacs.exe that you produce?
- Raw text -