wxPython building woes

[David Bolen]

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

> Excellent!  Thanks.  So, now I hit the next stumbling block: the
> library file actually built by the wxWindows build is called
> wxdll.lib; but the library file the generated Makefile wants
> must be called wx22_0.lib.  How do I fix _that_ -- just rename
> or copy the .lib?  I tried following the complex configuration
> logic and it seemed to me that setting WXVERSION=dll might help,
> so I tried adding that to OTHERDEFS in build.local, but it seems
> to make no difference.

That's actually due to a mis-match within wxWindows itself between
their IDE setup workspace and their makefile (makefile.vc).  I'm not
sure why (probably just out of sync - I recall it being discussed
recently on the wxWindows developer list) but the IDE VC devstudio
files use a different DLL name than the straight wxWindows makefile.vc
file.  And wxPython uses the straight makefile approach (including the
stock wxWindows files to get a bunch of wxWindows support), so it defaults
to the makefile version.

So one answer is just don't use the IDE for building and run the build
manually with the makefile (as noted in the build description for
wxPython - I think the only thing missing there is you also have to
include USE_GLCANVAS=1 on the makefile command line to get all the
linking right).

> I see... I've never been as grateful for the VS IDE as right now -- it
> took me all of 5 minutes to read the instructions and build wxWindows,
> while the wxPython build is proving just as much of a bother as I
> recalled software builds to be on Linux before autoconf & friends:-).

Interesting - I was so happy not to have to bother getting into the VS
IDE for wxWindows at all.  I just used the direct makefile.vc approach
and had no problems (and I get to stay in Emacs :-)) The VS stuff is
fine if everything is exactly right for your machine in the
distribution, but when you have to fix something then it gets fun.
And I think it's the problem of not being able to cleanly reference
one workspace from another (unless you build them that way to start
with) that probably kept wxPython in the makefile world - or maybe
Robin just likes prefers them as I do.  Oh well, to each his own :-)

But if you want to stick with the IDE, I'm sure it would be trivial to
change the output filename .. lemme see ... yeah, just bring up your
project settings (Project menu, Settings), select your appropriate
project (Win32 Release), and then on the Link tab just change the
output filename to wx22_0.dll.  I think that'll take care of the
import library as well but don't have the time to run a build to be
sure.

Or, conversely you could edit $WXWIN/src/makevc.env and change the
WXVERSION definition from "22_0" to "dll".  It'll look sort of
strange, but it'll create the right definitions for wxPython to use.

BTW, you were on the right track with WXVERSION - the problem is that
(unlike something like "FINAL") the wxWindows makefiles aren't
designed to let it be overridden.  So although you place it in
OTHERDEFS, when the generated Makefile includes makevc.env, it just
redefines it on top of you.  You have to change it in makevc.env.

> So, anyway, sorry to keep bothering, but since one must apparently
> acquire detailed knowledge of this intricate process to build
> wxPython on Windows (though not, thankfully, to build wxWindows
> itself) -- how do I now manage to convince the wxPython build to
> use the actual libraries that the wxWindows build produced...?

It's just a mismatch within wxWindows itself from their two distinct
build processes, which unfortunately you're tickling since you're
using both approaches at once.  That's really what needs fixing - they
need to pick a naming scheme and stick with it in both approaches.

Hope the above helps.

--
-- 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     \
\-----------------------------------------------------------------------/