[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14409: emacs 24.3 -- windows
From: |
Eli Zaretskii |
Subject: |
bug#14409: emacs 24.3 -- windows |
Date: |
Thu, 16 May 2013 21:42:53 +0300 |
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?