Re: Compiling (development) Emacs with MSVC

[Fabrice Popineau <fabrice.popineau@supelec.fr>]

[-- Attachment #1: Type: text/plain, Size: 6710 bytes --]

Sorry for the long delay before replying.

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?
>

No, that doesn't work. And somehow, I'm glad that the compiler can't be
fooled this way.
After looking around and googling about this issue, the problem is trickier
than what I thought
at first. Even my first explanation may not be complete. Anyway, mixing enum
and bit fields
seems to be incompatible with portability. Either you need to step back and
type bit fields
with int or unsigned int (and loose typechecking) or  you need to get around
with macros
taking care of using enum or unsigned ints depending on the compiler.




> 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?
>

Only reformatting, sorry. I'm not even sure that I needed to define
DECL_ALIGN for msvc,
because I set an option on the command line to align everything.



> >  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.
>

They are not invoked, but the problem is that they are not parsable. Nmake
fails to read the makefile.



> > -       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?


MSVC can't/doesnt want to do arithmetic on void pointers.


> > +#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 I don't do it, I get linking errors :
temacs2.lib(sysdep.obj) : error LNK2019: unresolved external symbol
__imp__stat referenced in function _sys_sigblock
temacs2.lib(image.obj) : error LNK2001: unresolved external symbol
__imp__stat
temacs1.lib(dired.obj) : error LNK2001: unresolved external symbol
__imp__stat
temacs1.lib(lread.obj) : error LNK2001: unresolved external symbol
__imp__stat
temacs1.lib(w32.obj) : error LNK2001: unresolved external symbol __imp__stat
temacs1.lib(fileio.obj) : error LNK2001: unresolved external symbol
__imp__stat
temacs2.lib(sysdep.obj) : error LNK2019: unresolved external symbol _utime
referenced in function _set_file_times

There are these 2 lines in src/s/ms-w32.h :

#if !defined (_MSC_VER) || (_MSC_VER < 1400)
#define tzname    _tzname
#define utime  _utime
#endif

If I raise the 1400 to a higher value to include my version of the compiler,
the compiler reports an error message about :

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\time.h(270) :
error C2090: function returns array

because tzname is defined as an array and that triggers a conflict.

Why would it be a problem to map thos three calls to their sys_ version ?
Performance ?

 > -      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?


_access doesn't know about D_OK. Worse, D_OK is defined, it hides the fact
that _access
doesn't know about it. But _access crashes with this value. Anyway,
sys_access is defined, so why
not using it ?


>

> -    " --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?


Oops. I used this hack long ago, and I reintroduced it. But my real problem
is that user_cflags contains
various -I<path> to find include files, and these paths have \ that are not
doubled.
Stringifying is a bad idea and doesn't solve the problem at all. Need to
find a better solution.



> > +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?


You may have several versions of the SDK. I put these lines to stress the
fact that people wanting
to compile emacs with the MS SDK need to set it up. Also, iti is needed to
set it up according to the debug/release mode.


> Also, how to
> set the /win7 switch portably, so that it works on non-Windows 7
> platforms as well?


This /win7 switch is unnecessary.


>  For that matter, is it at all necessary to call
> SetEnv.cmd, in addition to using appropriate compiler/linker switches?
>
>
I guess so, yes, to find the compiler, the include files and the libraries.

Also, note that to copile the whole thing, I need to run :

nmake USE_CRT_DLL=1

My best wishes for 2011.
Happy New Year.

Fabrice

[-- Attachment #2: Type: text/html, Size: 9573 bytes --]