compiling C-extensions with MSVC produce warning

[Alexander Belchenko]

Pyrex 0.9.6.4, bzr.dev revno.3763, Python 2.5.2:

There is warning C4007: 'WinMain' : must be '__stdcall'
It seems like some headers should be included in proper order.

Log of python setup.py build_ext:

running build_ext
pyrexc bzrlib/_btree_serializer_c.pyx --> bzrlib/_btree_serializer_c.c
building 'bzrlib._btree_serializer_c' extension
creating build\temp.win32-2.5
creating build\temp.win32-2.5\Release
creating build\temp.win32-2.5\Release\bzrlib
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -IC:\Python\2.5.1\include -IC:\Python\2.5.1\PC /Tcbzrlib/_btree_serializer_c.c /Fobuild\temp.win32-2.5\Release\bzrlib/_btree_serializer_c.obj
_btree_serializer_c.c
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\WinBase.h(1579) : warning C4007: 'WinMain' : must be '__stdcall'
creating build\lib.win32-2.5
creating build\lib.win32-2.5\bzrlib
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:C:\Python\2.5.1\libs /LIBPATH:C:\Python\2.5.1\PCBuild /EXPORT:init_btree_serializer_c build\temp.win32-2.5\Release\bzrlib/_btree_serializer_c.obj /OUT:build\lib.win32-2.5\bzrlib\_btree_serializer_c.pyd /IMPLIB:build\temp.win32-2.5\Release\bzrlib\_btree_serializer_c.lib
   Creating library build\temp.win32-2.5\Release\bzrlib\_btree_serializer_c.lib and object build\temp.win32-2.5\Release\bzrlib\_btree_serializer_c.exp
pyrexc bzrlib/_knit_load_data_c.pyx --> bzrlib/_knit_load_data_c.c
building 'bzrlib._knit_load_data_c' extension
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -IC:\Python\2.5.1\include -IC:\Python\2.5.1\PC /Tcbzrlib/_knit_load_data_c.c /Fobuild\temp.win32-2.5\Release\bzrlib/_knit_load_data_c.obj
_knit_load_data_c.c
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:C:\Python\2.5.1\libs /LIBPATH:C:\Python\2.5.1\PCBuild /EXPORT:init_knit_load_data_c build\temp.win32-2.5\Release\bzrlib/_knit_load_data_c.obj /OUT:build\lib.win32-2.5\bzrlib\_knit_load_data_c.pyd /IMPLIB:build\temp.win32-2.5\Release\bzrlib\_knit_load_data_c.lib
   Creating library build\temp.win32-2.5\Release\bzrlib\_knit_load_data_c.lib and object build\temp.win32-2.5\Release\bzrlib\_knit_load_data_c.exp
pyrexc bzrlib/_dirstate_helpers_c.pyx --> bzrlib/_dirstate_helpers_c.c
building 'bzrlib._dirstate_helpers_c' extension
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -IC:\Python\2.5.1\include -IC:\Python\2.5.1\PC /Tcbzrlib/_dirstate_helpers_c.c /Fobuild\temp.win32-2.5\Release\bzrlib/_dirstate_helpers_c.obj
_dirstate_helpers_c.c
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\WinBase.h(1579) : warning C4007: 'WinMain' : must be '__stdcall'
...

[Alexander Belchenko (bialix)]

Oh, it's a known Pyrex bug.
Workaround is the same as I do for walkdirs_win32: define macros WIN32.
Here the patch:

--- setup.py 2008-10-02 15:36:12 +0000
+++ setup.py 2008-10-03 09:59:46 +0000
@@ -226,18 +226,21 @@
              ext_modules.append(Extension(module_name, [c_name], **kwargs))

-add_pyrex_extension('bzrlib._btree_serializer_c')
  add_pyrex_extension('bzrlib._knit_load_data_c')
  if sys.platform == 'win32':
- add_pyrex_extension('bzrlib._dirstate_helpers_c',
- libraries=['Ws2_32']
- )
      # pyrex uses the macro WIN32 to detect the platform, even though it should
      # be using something like _WIN32 or MS_WINDOWS, oh well, we can give it the
      # right value.
+ add_pyrex_extension('bzrlib._btree_serializer_c',
+ define_macros=[('WIN32', None)])
+ add_pyrex_extension('bzrlib._dirstate_helpers_c',
+ libraries=['Ws2_32'],
+ define_macros=[('WIN32', None)],
+ )
      add_pyrex_extension('bzrlib._walkdirs_win32',
                          define_macros=[('WIN32', None)])
  else:
+ add_pyrex_extension('bzrlib._btree_serializer_c')
      if have_pyrex and pyrex_version == '0.9.4.1':
          # Pyrex 0.9.4.1 fails to compile this extension correctly
          # The code it generates re-uses a "local" pointer and

[Martin Pool (mbp)]

That looks ok to me, I'll merge it to 1.8 and trunk.

[Martin Pool (mbp)]

Fixed for 1.8rc2 or final.