wxPython building woes

[Alex Martelli]

"David Bolen" <db3l at fitlinxx.com> wrote in message
news:uhf8vifwt.fsf at ctwd0143.fitlinxx.com...
> "Alex Martelli" <alex at magenta.com> writes:
>
> > Where is this set...?  Not in build.cfg, apparently (can I
> > override it from there, or build.local? how?).  I grepped
> > for it throughout the tree, and can only find it in .OBJ files,
> > .DSP files, and vc6dll.t -- but that's just the template that
> > generates the .DSP etc, isn't it?
>
> Yes, you can control this with build.local - add the line:
>
> OTHERDEFS="FINAL=1"
>
> I did this in a build.local of mine right at the top of the wxPython
> tree.

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.


> This is a definition used by the wxWindows makefiles - if you weren't
> using the IDE for the wxWindows build, you'd need to supply it on the
> command line in your make command for wxWindows as well.

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

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


Thanks for all the help & support so far, btw, folks!


Alex