bug#14409: emacs 24.3 -- windows

[Eli Zaretskii <eliz@gnu.org>]

Once again, please keep the bug address on the list of addressees.

> Date: Thu, 16 May 2013 14:34:06 -0400
> From: Frank P Esposito <fpesposito@gmail.com>
> 
> nt\nmake.defs the text starting at line 119 or so,
> 
> 
> USE_CRT_DLL     = 1
> 
> !if USE_CRT_DLL
> libc            = msvcrt$(D).lib
> 
> 
> I think if the “!if” is checking for the value of  USE_CRT_DLL so it should
> read
> 
> !if $(USE_CRT_DLL)

Ah, OK.  This is already fixed in the development sources.

> I will also get you some more info on the linking issues

Thanks.

> for the macros vs inline function. If I have a define
> 
> #define MYFUNC( foo, bar )
> 
> and want to turn this is a a function signature I need to know the
> datatypes of
> foo and bar for the prototype, ie
> 
> void INLINE *f_myfunc( void *foo, void *bar ) { .... }
> #define MYFUNC( foo,bar ) f_myfunc( foo, bar )

I understand.  But I would like to avoid converting macros into
functions, as much as possible.  Let's first try to understand what
exactly the compiler doesn't like.

> About where the macro is failing, I guess that the old ms/c
> compilers have a limit to how complex the such expression can be, so
> if the project notes that visual c is supported from version 2, then
> the code would have to be written to the least common interface

Again, I'd like to see the macro that fails to compile, so far you
have shown me an expansion that I cannot compare with the original
source.

> Was there any thought on using open watcom c/c++

With GCC for Windows available, why would we go for Watcom?