From: "Tim Van Holder" To: "Eli Zaretskii" Cc: Subject: RE: gettext pretest available Date: Sun, 4 Mar 2001 20:06:07 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <2593-Sun04Mar2001200222+0200-eliz@is.elta.co.il> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > 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. Agreed - but that's a large part how emacs configures itself for a certain system. Besides, a DJGPP package is not supposed to contain corrupted files. Especially if we start to use zippo, the chance of there being a corrupt .elc file not introduced by the user becomes minimal. > 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. I didn't add another envvar, just another #define in epaths.h. > > 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. Yes, but the list of functions emacs shouldn't use is probably fairly costant (perhaps changing with DJGPP releases). As such, adding #undef's to s/msdos.h isn't unwarranted (and #undef's could and should be added even for functions emacs currently doesn't try to use). > > * 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? Don't see how; I don't set INFOPATH anywhere and "C-h i" works just fine. > > 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? Current .exe in $DJDIR/bin is 4MB - but that's with some extra packages loaded and with the gettext stuff included. How else would you dump emacs? Last time I checked, it didn't work if temacs was stubbed, and AFAIK you need to use 'go32 foo' to run an unstubbed COFF image. AFAICS, the djgpp package does the same thing (sed1x.inp changes './temacs' to 'go32 temacs').