Mail Archives: djgpp-workers/2001/03/04/11:50:36
> 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.
Oh ok - I didn't know that.
> 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.
I know - but I like to use emacs as an autoconf testcase; as such, I
wanted to build using configure. The only function I know of I needed to
disable was select(); it messed up the mouse support. But that was easily
fixed in s/msdos.h. Similarly, I needed to define USER_FULL_NAME to
pw->pw_name, as we have no pw_gecos (which reminds me - I need to resubmit
that patch to add the missing fields to struct passwd and struct group).
> - 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.
Anyway, I think emacs figures this out at startup or dump 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).
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. This allows you
to have emacs.exe in either $DJDIR/bin or $DJDIR/share/emacs/20.7/bin
or whatever, and it will still work (provided its etc, lisp, etc stuff
remains in this dir (in my case $datadir/emacs/$version)).
> - 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.
I didn't consider this point though; is there a list of such functions, or
should I just look through the sed scripts?
> - 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).
> > 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.
[Downloading and extracting official tarball to make comparison... Done]
[Diff: 15MB - Removing useless diffs (info, leim) -> 3MB]
I downloaded the original source just to make a diff; I'll note the
relevant portions below (most of the changes result from my hacking to
add NLS support to emacs).
> 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.
Hmm - think I did (pretty certain about leim, TAGS and man, not sure about
lisp).
> > 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?
Yep - my local sources were packaged up as zipfiles and only taken out of
mothballs today to run a diff against the official tarball.
> 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
Must say I don't have any problems with 20.7 (built with 2.03), probably
because of the added PATH_INSTALLATION. With earlier versions I did have
trouble with paths.
> 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.
I guess - but if we can get emacs to build and work reliably inside the
regular DJGPP tree _and_ standalone (is unsetting $DJGPP sufficient to
simulate a DJGPP-free environment?), I think that would be a Good Thing(tm).
OK - here goes: short overview of changes I made to emacs (gettext-related
changes omitted). Note: I've tried to give a complete list; some changes
are purely for personal preference (as this was a private build) and can
therefore be ignored.
* configure.in
Adjusted for autoconf 2.49a. Support for DOS-style absolute paths added.
Recognize i?86-pc-msdosdjgpp and set opsys to msdos. Check for socket()
in -lsocket and -linet. Set up paths using ';' if on DOS. Set GDBINIT
to gdb.ini on DOS. Added AC_EXEEXT (no longer needed with current CVS
autoconf).
I also set and AC_SUBST an 'installdir' variable
($datadir/emacs/$version).
This is used to set a default for installation-directory (in case emacs
can't deduce this itself).
* lib-src/etags.c
Add cbl to list of Cobol suffixes.
* lib-src/Makefile.in
Use $(exeext) (@EXEEXT@) where applicable. Use -o $@.
* lib-src/yow.c
Disable the definition of rootrelativepath if DJGPP >= 2.03.
* lisp/dired.el
Some minor customization to fontification.
* lisp/dos-w32.el
Add some additional extensions to file-name-buffer-file-type-alist (.sym,
.chk, .out, .cpl, .vbx, .ocx, .hlp, .chm, .png, .gif, .mp[23aegv], .rar,
.ace, .arj, .lzo, .bz2, .tgz). Default buffer-file-coding-system to
'undecided; using 'undecided-dos breaks jka-compr. Same change to the
'write-region part of find-buffer-file-type-coding-system.
* lisp/ediff-diff.el, lisp/ediff-util.el, lisp/ediff.el
Add
(and noninteractive
(eval-when-compile
(load-library "term/pc-win")))
Don't remember why though; might be fontification-related.
* lisp/autoload.el
Use installation-directory instead of source-directory when expanding
the name of the generated autoloads file.
* lisp/finder-inf.el
Regenerate.
* lisp/info.el
Support a bz2 suffix (-> bunzip2). Bind [backtab] to Info-prev-reference
on msdos (our standalone info reader does that too).
* lisp/international/mule.el
Add gz/GZ, bz2/BZ2 and lzo/LZO to list of extensions that map to
'no-conversion in auto-coding-alist.
* lisp/jka-compr.el
Add support for bzip2 and lzop to jka-compr-compression-info-list.
Always use raw-text as coding-system-for-read on dos/nt.
* lisp/ls-lisp.el
Don't strip the directory in ls-lisp-insert-directory; this breaks vc.
* lisp/Makefile
Add 'SHELL = /bin/sh'.
* lisp/term/pc-win.el
Add sienna (red) and royalblue (blue) to color mappings. Set several
default faces; add customization support for the msdos faces. Disable
the displaying of the command line at startup. Provide 'pc-win.
* Makefile.in
Use $(exeext) where applicable. Use correct pathsep in removenullpaths
(uses @PATH_SEPARATOR@, which is specific to either my old patched
autoconf, or autoconf > 2.49d). Use '|' instead of ';' as separator in
several sed scripts. Set up PATH_INSTALLATION (from @installdir@).
[Here reading the diffs became hard, as I had gettextized most string
literals, resulting in a heap of irrelevant diffs. So I may have missed
some of the changes I made.]
* src/callproc.c
On MSDOS, set Vinstallation-directory in init_callproc_1 (using
PATH_INSTALLATION).
* src/dispnew.c
Default visible_bell to 1.
* src/dosfns.c
Call my modified dos_set_keyboard with '0, 0' to deduce layout before
calling it with the country code we got from DOS (see below).
Add mapping for Belgium (country code 32 -> codepage 850). Rename
w95_set_virtual_machine_title() to w9x_set_title() and add a parameter to
specify what string to set (VM or app title). Add a Lisp interface to it
(set-w95-titlebar-string). Add a Lisp function to retrieve the current
value of these strings (w95-titlebar-string). Add 'vm-title and
'app-title
symbols to use as params for these. Define x_set_name() and
x_implicitly_set_name(); have them use w9x_set_title().
* src/emacs.c
Default Vinstallation_directory to Qnil on non-MSDOS systems.
* src/epaths.in
On MSDOS, define PATH_INSTALLATION.
* src/Makefile.in
Use $(exeext) where appropriate.
Add DJGPP-specific undumping commands:
go32 temacs -batch -l loadup dump
stubify emacs; rm -f emacs
stubedit $@ minstack=3m bufsize=48k argv0=Emacs
test -d ../bin || mkdir ../bin
cp ${libsrc}fns.el ../bin/fns.el /* emacs doesn't search lib-src on DOS */
On DJGPP, make sure we get a pure COFF temacs:
#ifdef __DJGPP__
rm -f temacs
#endif
$(LD) YMF_PASS_LDFLAGS (${STARTFLAGS} ${ALL_LDFLAGS}) -o $@ ${STARTFILES} \
${obj} ${otherobj} OBJECTS_SYSTEM OBJECTS_MACHINE ${LIBES}
#ifdef __DJGPP__
if test -f temacs; then mv temacs temacs.exe; else true; fi
exe2coff temacs.exe
rm -f temacs.exe
#endif
* src/msdos.c
At startup, increase re_max_failures to 12000 to increase the stack for
the
regexp matcher (cfr the increased stack size set for emacs.exe above).
This
is quite arbitrary; it should probably be a customizable Lisp variable.
Initially move mouse to upper right corner instead of upper left corner.
Default colors to bright white on black.
Add Belgian keyboard.
Add text version (e.g. "US") to struct keyboard_layout_list.
Extend dos_set_keyboard(); if passed zero for both arguments, it will ask
keyb.com (if present) for the country code (int 2f/ad80) and look it up in
the layout list.
Map kp-enter to newline instead of return (so it can be used instead of
C-j
to eval the current expression in lisp-interaction-mode).
Default root to '..' if not initialized (emacsroot isn't initialized until
after emacs is dumped).
Use _truename to get root from argv0, taking care not to break if argv0
isn't real. (I like getting the LFN version of argv0 when under Win9x)
Favor $DJDIR over c:/emacs as root.
Don't default EMACSPATH; we use PATH_EXEC now
($datadir/emacs/$version/libexec)
Don't even try fiddling with COMSPEC if $SHELL is set.
Provide default for $GROUP as well as user (root/emacs).
Correct comments in TZ switch (31 = The Netherlands; 32 = Belgium).
* src/s/msdos.h
Provide #define for USER_FULL_NAME (pw->pw_name).
Undefine HAVE_SELECT.
There. Done. Actually, this brought me up-to-speed with emacs again, so I
can
now go and hack away at the pretest... Thanks Eli :-)
- Raw text -