I used SWIG (http://www.swig.org) to to create the source code for the extension module. This enabled me to only have to deal with a small amount of code and only have to bother with the exceptional issues. SWIG takes care of the rest and generates all the repetitive code for me. You don't need SWIG to build the extension module as all the generated C++ code is included under the src directory.
I added a few minor features to SWIG to control some of the code generation. If you want to play around with this you will need to get a recent version of SWIG from their CVS or from a daily build. See http://www.swig.org/ for details.
wxPython is organized as a Python package. This means that the directory containing the results of the build process should be a subdirectory of a directory on the PYTHONPATH. (And preferably should be named wxPython.) You can control where the build process will dump wxPython by setting the TARGETDIR variable for the build utility (see below).
--with-gtk --with-libjpeg --without-odbc --enable-unicode=no --enable-threads=yes --enable-socket=yes --enable-static=no --enable-shared=yes --disable-std_iostreamsYou can use whatever flags you want, but I know these work.
For Win32 systems I use Visual C++ 6.0, but 5.0 should work also. The build utility currently does not support any other Win32 compilers.
python %WXWIN/utils/wxPython/distrib/build.py %1 %2 %3 %4 %5 %6
The build.py script actually generates a Makefile based on what it finds on your system and information found in the build.cfg file. If you have troubles building or you want it built or installed in a different way, take a look at the docstring in build.py. You are able to override many configuration options in a file named build.local.
python demo.py
To run it without requiring a console on Win32, you can use the pythonw.exe version of Python either from the command line or from a shortcut.