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

[Mark H. <mha...@sk...>]

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

No, but pywintypes.dsp and win32com.dsp on the head will be missing some
files.  I haven't built as 2.4 for a long time now.  I just keep a sticky
"Python23" tag on pywintypes.dsp and win32com.dsp for day to day work, and
this is part of the reason I want to use this setup file - drop those stupid
CVS branches for those 2 stupid makefiles :)  "cvs up -j python23
win32com.dsp" etc may do it.

> Apart from that, I also did get servicemanager and perfmon to build:

Thanks - added!

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

Correct - it is not an extension module - it is a perfmon data provider DLL

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

For some of the SWIG files, I try and handle both CE and Win32 with some
magic.  The basic idea is:

* win32event.i generates to either win32eventmodule_win32.cpp or _wince.cpp
* win32eventmodule_win32.cpp and win32eventmodule_wince.cpp are *not* in
CVS.
* win32eventmodule.cpp - hand written - #includes
win32eventmodule_win32.cpp/_wince.cpp

That is the intent, and appears to be true for win32event.  win32service
seems a little confused, but this module would never have been built on CE.

> Also I have the impression that the generated swig-wrappers
> are checked
> in CVS, which does not help because it masks build errors.

That should not be true.  Some that *look* like they are would be as
described above - ie, the small "win32eventmodule.cpp" which only #includes
the generated one.  (Recently with the mainwin stuff though, I've been
wishing they *were* in CVS, as I can't run my SWIG there ;)

I'd be happy to make all this consistent, including changing the .dsp files.

And while you are here :)  MingW.  I get the impression that MingW can
compile extensions to be used with an MSVC built Python.  However, I appear
to see distutils croak:

>python setup_win32all_core.py build -cmingw32
running build
running build_ext
warning: Python's pyconfig.h doesn't seem to support your compiler. Reason:
couldn't read 'E:\src\py
thon-2.3-cvs\include\pyconfig.h': No such file or directory. Compiling may
fail because of undefined
 preprocessor macros.

Is there additional magic I need to point it at the PC directory?

Thanks

Mark.