From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Compiling (development) Emacs with MSVC Date: Sat, 18 Dec 2010 13:05:58 +0200 Message-ID: <83oc8jfii1.fsf@gnu.org> References: <83sjy5279e.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1292670375 11965 80.91.229.12 (18 Dec 2010 11:06:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 18 Dec 2010 11:06:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Fabrice Popineau Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 18 12:06:09 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PTubx-0007wx-8A for ged-emacs-devel@m.gmane.org; Sat, 18 Dec 2010 12:06:01 +0100 Original-Received: from localhost ([127.0.0.1]:49874 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PTubw-0000BG-NZ for ged-emacs-devel@m.gmane.org; Sat, 18 Dec 2010 06:06:00 -0500 Original-Received: from [140.186.70.92] (port=56161 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PTubr-0000B6-Se for emacs-devel@gnu.org; Sat, 18 Dec 2010 06:05:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PTubq-0001HD-GM for emacs-devel@gnu.org; Sat, 18 Dec 2010 06:05:55 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:47422) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PTubq-0001H7-8Y for emacs-devel@gnu.org; Sat, 18 Dec 2010 06:05:54 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LDM00F00ELV6A00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 18 Dec 2010 13:05:52 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.229.167.122]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LDM00D1TETQSUD0@a-mtaout22.012.net.il>; Sat, 18 Dec 2010 13:05:52 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:133787 Archived-At: > From: Fabrice Popineau > Date: Mon, 13 Dec 2010 23:40:56 +0100 > Cc: emacs-devel@gnu.org > > Patch attached. Thanks. I finally found time to review it, and I have a few comments and questions: > Apparently the ANSI C spec says that bit fields are unsigned, and enum are > signed, hence the patch in lisp.h for various bit fields. > Anyway, the MS compiler did extend sign and that was the main failure. The problem and the solution you suggest are clear, but I'd like to try to find a cleaner solution, if possible, one that doesn't require so many #ifdef's. Can you think of some change in one or two places that would resolve this? Can MSVC be forced in some way to use an unsigned type for enumerations, for example? If not, since the problem is only with a single enumeration, would it work to use something like this: enum Lisp_Misc_Type { Lisp_Misc_Free = 0x5eab, Lisp_Misc_Marker = 0x5eac, Lisp_Misc_Intfwd = 0x5ead, etc.? Or maybe use 0x5eabU etc., with an explicitly unsigned value? A few other issues with the rest of the patch: > -# define DECL_ALIGN(type, var) \ > +# define DECL_ALIGN(type, var) \ > type __attribute__ ((__aligned__ (1 << GCTYPEBITS))) var Is this just some inadvertent reformatting, or is there some deeper problem here? > TAGS-gmake: > - ../lib-src/$(BLD)/etags.exe --include=TAGS-LISP --include=../nt/TAGS \ > - --regex=@../nt/emacs-src.tags \ > - $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ0)) > - ../lib-src/$(BLD)/etags.exe -a --regex=@../nt/emacs-src.tags \ > - $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ1)) > - ../lib-src/$(BLD)/etags.exe -a --regex=@../nt/emacs-src.tags \ > - $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ2)) \ > - $(CURDIR)/*.h > +# ../lib-src/$(BLD)/etags.exe --include=TAGS-LISP --include=../nt/TAGS \ > +# --regex=@../nt/emacs-src.tags \ > +# $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ0)) > +# ../lib-src/$(BLD)/etags.exe -a --regex=@../nt/emacs-src.tags \ > +# $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ1)) > +# ../lib-src/$(BLD)/etags.exe -a --regex=@../nt/emacs-src.tags \ > +# $(patsubst $(BLD)%.$(O),$(CURDIR)%.c,$(OBJ2)) \ > +# $(CURDIR)/*.h Why did you comment out these commands? They are not supposed to be invoked under nmake, only under GNU Make. > - memset (bloc->new_data + old_size, 0, size - old_size); > + memset ((char *) bloc->new_data + old_size, 0, size - old_size); Is this a real problem, or just a left-over from some attempt to debug memory allocation problems, resolved by "-dynamicbase:no"? If this is a real problem, can you tell what it is? > +#define fstat(a, b) sys_fstat(a, b) > +#define stat(a, b) sys_stat(a, b) > +#define utime sys_utime Why did you need to do this? What happens if you don't? > - if (tmp && _access (tmp, D_OK) == 0) > + if (tmp && sys_access (tmp, D_OK) == 0) What's wrong with calling _access from the MS runtime? > - " --cflags", USER_CFLAGS, > + " --cflags", stringer(USER_CFLAGS), Why did you need to stringify here? USER_CFLAGS is supposed to be defined to a quoted string, like " -DFOO". Can you tell why this didn't work for you? > +rem set SDK environment > +if (%noopt%) == (Y) ( > + call "c:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x86 /win7 /Debug > + set nodebug=N > +) > + > +if (%nodebug%) == (Y) ( > + call "c:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x86 /win7 /Release > + set noopt=N > +) Is there a less system-dependent way of doing this? E.g., is there an environment variable to replace the path to SetEnv.cmd? Also, how to set the /win7 switch portably, so that it works on non-Windows 7 platforms as well? For that matter, is it at all necessary to call SetEnv.cmd, in addition to using appropriate compiler/linker switches? Thanks.