Re: [pywin32-checkins] pywin32 setup_win32all_core.py,1.6,1.7

[Thomas H. <th...@py...>]

mha...@us... writes:

> Update of /cvsroot/pywin32/pywin32
> In directory sc8-pr-cvs1:/tmp/cvs-serv25361
>
> Modified Files:
> 	setup_win32all_core.py 
> Log Message:
> Get most of the win32 .pyd extensions building.

I had somewhat similar things in my setup script. I didn't check them in
because I could not build the HEAD revision, checking out b163 (or how
it's called) worked.  Do you still have some uncommited changes
somewhere? IIRC, building the pythoncom dll failed, and the linking step
complained among other things that Py_NewSTGMEDIUM or so is not found.

Apart from that, I also did get servicemanager and perfmon to build:
servicemanager = WinExt('servicemanager',
                        extra_compile_args = ['-DPYSERVICE_BUILD_DLL', '-DUNICODE', '-D_UNICODE'],
                        dsp_file = r"win32\Pythonservice servicemanager.dsp")

perfmon = WinExt('perfmon',
                 extra_compile_args = ['-DUNICODE', '-D_UNICODE'],
                 dsp_file = r"win32\perfmon.dsp")

perfmondata does not build, because it's not an extension module (?),
and I think this was the build target that triggered the problems I
posted to distutils mailing list.

Anyway, I think there's still a problem with swig creating the wrappers.
I had to change the name of the generated cpp file to
                swig_targets[source] = base + 'module' + target_ext
but it seems there is no consistent naming convention for the
swig-created wrappers. Have to check in the dsp files.

Also I have the impression that the generated swig-wrappers are checked
in CVS, which does not help because it masks build errors.  Now that you
have your own swig in the source tree, this should be avoided IMO.

Thomas