wxPython building woes

[David Bolen]

"Alex Martelli" <alex at magenta.com> writes:

> Does anybody have a successful binary build of wxPython for
> Python 1.6b1 under Win/98?  And is willing to share either the
> DLL or the various pieces of configuration-etc-file magic that
> let it be built...?

I don't have 1.6b1 around, but I do have the following in my
build.local file:

PYPREFIX="d:\\pkg\\python"

where d:\pkg\python is where Python 1.5.2 is installed on my system
which is what I was building against.  I should have probably
mentioned it in my prior post - that plus the OTHERDEFS are the only
two things I have in my build.local.

The wxPython process automatically includes $PYPREFIX\include as an
additional search path.

Note that as you say, the Python source tree itself does not have
config.h in its include directory, but an installation of Python does.
Presumably that's because for PC users the config.h is fixed whereas
for Unix users it's the output of the autoconf-based configure run.
The appropriate version is then placed in the real installation
directory during installation.  wxPython appears designed to build
against a standard Python install (makes sense, since it's an
extension).

So if you are trying to build wxPython against the raw source tree of
1.6b1 (or even an earlier version) directly (as opposed to a copy of
1.6b1 actually installed somewhere on your system), you've got to tweak
a few other things in your build.local:

Try adding (where PYROOT is the root of your 1.6b1 source tree):

PYPREFIX="<ROOT>"
OTHERCFLAGS="-I<ROOT>\\pc"
PYTHONLIB="<ROOT>\\pcbuild\python16.lib"  (or whatever the lib name is)

(BTW, these settings are defined at the top of build.py and also displayed
when it dumps usage information).

Now, having just tried this myself with a recent 2.0 snapshot from
CVS, this doesn't resolve the duplicate definition of the wide stuff.
And you correctly identified the root cause (the file being included
within a "C" block).

I'm not sure about your comment about knowing what's being compiled -
at least in my case, I see the file being compiled just fine (just in
front of the errors - normal make output).  I did a clean first (build
-c) so it's the very first file (wx.cpp).  But it happens on any file.

This was sort of intriguing (first time I tried to build against 2.0)
so I poked and the problem here seems to have little to do with
wxPython or wxWindows directly, but rather has to do with the default
code that SWIG generates for Python - it's not compatible with Python
1.6/2.0.  At least with the variant of SWIG I have installed (1.1
build 883 - I just grabbed it within the past 2 weeks), it's default
configuration for Python includes the following in at least the
python.swg and pyexp.swg files:

    #ifdef __cplusplus
    extern "C" {
    #endif
    #include "Python.h"

which ends up including all of Python in the extern "C" block.
Doesn't hurt with 1.5.2, but blows up 2.0 and presumably 1.6.

I just edited those two .swg files to move the #include "Python.h"
above the #ifdef, and then re-ran it on wxPython (just touch the .i
files, since the default wxPython stuff tries to avoid forceing a
re-run of swig so users don't necessarily have to have it installed)
and it does seem to be compiling properly.  My source tree is sort of
a partial main branch of wxWindows and I'd have to rebuild clean to be
able to link against all of the wxPython support so I didn't get a
full link finished yet, but it's looking fairly normal with what did
build.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/