[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Building Emacs with MSVC
From: |
Christoph |
Subject: |
Re: Building Emacs with MSVC |
Date: |
Tue, 06 Apr 2010 22:49:27 -0600 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 |
On 4/6/2010 9:13 PM, Eli Zaretskii wrote:
Yes, Studio 2003 is the last version known to build a working binary.
OK.
That's a known problem. I forget the details (you can find them in
the archives), but there's some problem with the library functions
supplied by later versions of Studio, and/or conflicts with our
customized malloc, that cause the crash.
Yes, one issue is the library libc.lib (single threaded) which was
replaced by libcmt.lib (multithreaded). But there were other issues like
shadowing functions, for example sys_ctime and utime.
Also, maybe this is interesting for you Eli: bidi.c failed because MSVC
does not support the inline keyword for C files (only for C++ files).
__inline is the correct keyword for C files
(http://msdn.microsoft.com/en-us/library/z8y1yy88.aspx) in MSVC.
It might not matter, since GCC compiles fine, but I though I'd mention
it anyway.
What for? If we cannot build a working binary, why pollute the
sources with more MSVC-specific patches?
The patch is actually for a bug in the existing MSVC makefile in
lib-src. I am pretty sure even older versions would not run with this,
since nmake fails right away:
=== modified file 'lib-src/makefile.w32-in'
--- lib-src/makefile.w32-in 2010-04-03 01:54:24 +0000
+++ lib-src/makefile.w32-in 2010-04-06 03:06:03 +0000
@@ -195,8 +195,8 @@
$(lispsource)term/pc-win.elc \
$(lispsource)x-dnd.elc \
$(lispsource)term/x-win.elc \
- ${lispsource}emacs-lisp/easymenu.elc \
- ${lispsource}term/ns-win.elc
+ $(lispsource)emacs-lisp/easymenu.elc \
+ $(lispsource)term/ns-win.elc
Right. And since MinGW is available and in pretty good shape, we
decided at the time not to invest any effort in MSVC.
I agree. MinGW works absolutely fine, so is there even any reason to
keep the MSVC stuff around? Was MSVC supported earlier than MinGW? I
surely don't want to start another discussion about backwards
compatibility and supporting older versions but a lot areas could be
cleaned up quite a bit if MSVC/nmake support was dropped in favor of
MinGW/gmake. The only reason for the zipdist batch file was nmake, which
turns out to be horribly limited compared to gmake.
Just my $0.02,
Christoph