RE: [h-e-w] Compiling Emacs on Windows a piece of cake!

[Ben Key]

I was able to reproduce, and fix, the problem you are experiencing with
building the 21.2 sources with MinGW.  Here is a patch file that will
resolve the issue.  Note: This issue does not happen with the CVS sources
for Emacs 21.3.50.
<PATCH>
--- _21.2/src/w32fns.c  2002-03-13 13:52:22.000000000 -0500
+++ 21.2/src/w32fns.c   2002-10-15 23:15:36.000000000 -0400
@@ -13969,17 +13969,17 @@
 WINDOWS_CHARSET is a symbol that can be one of:\n\
 w32-charset-ansi, w32-charset-default, w32-charset-symbol,\n\
 w32-charset-shiftjis, w32-charset-hangeul, w32-charset-gb2312,\n\
-w32-charset-chinesebig5, "
+w32-charset-chinesebig5, \n\
 #ifdef JOHAB_CHARSET
-"w32-charset-johab, w32-charset-hebrew,\n\
+w32-charset-johab, w32-charset-hebrew,\n\
 w32-charset-arabic, w32-charset-greek, w32-charset-turkish,\n\
 w32-charset-vietnamese, w32-charset-thai, w32-charset-easteurope,\n\
-w32-charset-russian, w32-charset-mac, w32-charset-baltic,\n"
-#endif
-#ifdef UNICODE_CHARSET
-"w32-charset-unicode, "
-#endif
-"or w32-charset-oem.\n\
+w32-charset-russian, w32-charset-mac, w32-charset-baltic,\n\
+#endif\n\
+#ifdef UNICODE_CHARSET\n\
+w32-charset-unicode, \n\
+#endif\n\
+or w32-charset-oem.\n\
 CODEPAGE should be an integer specifying the codepage that should be
used\n\
 to display the character set, t to do no translation and output as
Unicode,\n\
 or nil to do no translation and output as 8 bit (or multibyte on
far-east\n\
</PATCH>

I was able to build the 21.3 sources using MingW / MSys without so much
trouble.  The trick is to download all of the newest stuff, even the 1.08
release candidate of msys (1.07 crashes in sh.exe while doing the build).

Note: If running on Windows NT, make certain to set the ComSpec environment
variable to %WINDIR%\System32\CMD.EXE.  If it is set to something else, such
as 4NT.EXE, all kinds of weird errors result.

-----Original Message-----
From: address@hidden
[mailto:address@hidden Behalf Of Underwood,
Jonathan
Sent: Monday, October 14, 2002 3:06 PM
To: 'Jason Rumney'; Underwood, Jonathan
Cc: 'address@hidden'; address@hidden
Subject: RE: [h-e-w] Compiling Emacs on Windows a piece of cake!


Hi

Unfortunately i am still unable to build emacs, either the cvs version or
the 21.2 sources. I'm using mingw and msys, and have tried both makes that
come with this system (having excluded all possibility that cygwins make or
gcc's etc are still being used) both through msys, and through a cmd.exe
console window. This is on windows 2000. I am runninging configure.bat in
the nt directory, followed by make bootstrap (or mingw32make.exe bootstrap)
at which point it fails. For the 21.2 sources which i have reverted to, i
get the error :

w32fns.c: In function `syms_of_w32fns':
w32fns.c:13974: `DEFVAR_LISP' undeclared (first use in this function)
w32fns.c:13974: (Each undeclared identifier is reported only once
w32fns.c:13974: for each function it appears in.)
w32fns.c:13974: parse error before string constant
mingw32-make.exe[2]: *** [oo-spd/i386/w32fns.o] Error 1
mingw32-make.exe[2]: Leaving directory `e:/emacs-21.2/src'
mingw32-make.exe[1]: *** [bootstrap-temacs] Error 2
mingw32-make.exe[1]: Leaving directory `e:/emacs-21.2/src'
c:\mingw\bin\mingw32-make.exe: *** [bootstrap-gmake] Error 2


I would likle to resolve these building problems as i was hoping to
contribute to ntemacs, but i seem to be stuck at the very first hurdle.

cheers,

jonathan.

> -----Original Message-----
> From: Jason Rumney [mailto:address@hidden
> Sent: October 10, 2002 5:32 PM
> To: Underwood, Jonathan
> Cc: 'address@hidden'; address@hidden
> Subject: Re: [h-e-w] Compiling Emacs on Windows a piece of cake!
>
>
> "Underwood, Jonathan" <address@hidden> writes:
>
> > As an aside, with the availability of mingw and cygwin, I
> wonder if the
> > ntemacs port couldn't be configured by the usual congigure
> script in the
> > base source directory as it would on any other unix system,
> or is this
> > something to do with keeping compatibility with MSVC ?
>
> Even mingw32 tools are Windows programs that need Windows
> paths. Also, the standard configure script would require a bourne
> compatible shell.
>
> The cygwin build does use the standard configure scripts AFAIK, but
> does not do native Windows display (and probably has numerous other
> bugs lurking due to the fact that Windows is different in many ways
> to Unix-like systems, no matter how transparent cygwin tries to make
> this).
>
>
>
>