wxPython building woes

[Alex Martelli]

"David Bolen" <db3l at fitlinxx.com> wrote in message
news:ur97zqay0.fsf at ctwd0143.fitlinxx.com...
 > "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
    [snip]
> That's actually due to a mis-match within wxWindows itself between
> their IDE setup workspace and their makefile (makefile.vc).  I'm not

A-*ha*!  *Thank* you.  I would never have guessed that; but now I
can see my way clear to it, I think...


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

I'm used to VC++'s IDE, it gives me handy access to all tools I need
(NuMega's, Intel's, etc -- they all integrate -- and most importantly,
of course, *VIM*!-).  I do work shoulder-to-shoulder with a die-hard
Emacs'er, so I understand 2nd-hand what it means to "stay in Emacs",
but us old-time VI-ers have different attitudes...:-).


> fine if everything is exactly right for your machine in the
> distribution, but when you have to fix something then it gets fun.

Easier, IMHO, than browsing around for a configuration that is
half-implicitly specified in each of half a dozen textfiles.  At
least stuff is in ONE place.  But I guess it depends on one's actual
experience and background attitude.

> 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 :-)

No reference between _workspaces_ (.DSW), but no problem in
building a workspace that accesses whatever _projects_ (.DSP)
you want -- and config information is in the projects, all the
workspace does is "hang" them together (oversimplifying, OK,
I confess, but not by much).


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

Yes, it should work just fine.  I'm doing it at home, not here at work, but
this evening the fix will/should be easy.

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

And save me a relink:-).  I have the impression my built-for-1.6b1
thingies are not going to stay around long anyway:-).

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

This is quite clear, thanks.  Part of the problem with an ad-hoc config
setup (or rather with trying to pick it up in a hurry as I was doing:-) --
it's never obvious which settings override which other ones:-).


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

I'm sure it will -- you know, that effect of a light suddenly going on
in one's head.  *THANKS*!


Alex