Line Benchmarks Tkinter vs. wxPython

[Mitch Chapman]

Randall Hopper wrote:
> wxWindows fails to build under IRIX (dialog.cpp only knows Sun, Linux, or
> FreeBSD...).  configure --disable-dialupman works around the problem.

Yesterday I also tried compiling wxWindows & wxPython for IRIX.
My situation was complicated by the need to use the O32 ABI together
with the MIPSpro (spel?) compilers.  Although most of the resulting
problems are due to the compiler and not to wxWindows/wxPython,
they may be interesting from a portability point of view.

> wxWindows and wxPython both presume GNU make.  env MAKE=gmake ... works
> around this for wxWindows, but not so for wxPython:
> 
>   > env MAKE=gmake python $WXWIN/utils/wxPython/distrib/build.py -b
>   Makefile created:  Makefile
>   Running: make -f Makefile
>   make: file `Makefile' line 84: Must be a separator (: or ::) for rules (bu39)
>   ...
> 
> Would be nice if build.py took its queues off of os.environ["MAKE"].  I
> hacked sys.MAKE in build.py.

You can also specify the option on the command line, e.g.

build.py -b MAKE=gmake

But this works only when the righthand side of the assignment
does not itself contain an '='.  If the righthand side *does*
contain an '=', you need to copy build.cfg to build.local and 
insert the definition for the variable in question.

Finding out which variables to set is not too hard, but does
require contemplation of the build.py docstring.

> Then it failed finding wx.h.

As you discovered, the fix is to unpack the wxPython tarball
under the utils directory of wxWindows.  And as you noted, the
README is not clear on this point.  It also took me awhile to
realize that you need to define the WXWIN environment variable --
it wasn't needed during the build of wxWindows.


My next set of problems stemmed from the need to use the MIPSpro
compilers w. the O32 ABI.

The most severe of these is that, when compiling for the O32 ABI, 
the C++ compiler does not predefine type bool or the constants true 
or false.

wxWindows handles this situation by providing a typedef for bool,
if one is not already present, and defining the preprocessor macros
TRUE and FALSE.  It would be nice if wxPython used these same
definitions.  It took some time to figure out that I didn't need a
typedef for bool (since it was supplied by wxWindows) but *did* need
definitions for the constants true and false.

The second problem probably also is due to the compiler:
I got error messages for every reference to NULL.  Since the C++
idiom is to use an uncast '0' as NULL, a simple preprocessor
directive (-DNULL=0) solved this problem.

The third problem was the use of C++-style comments in src/libpy.c.
Use of '//' as a comment delimiter in C source code is not
portable.  (Okay, it's portable if everybody's using GCC.  But
it isn't part of the ANSI spec, is it?)

The last problem arose because wxPython expects to use the latest
CVS'd version of SWIG.  We don't have the latest SWIG, and
my account is already overflowing with "personal" builds of
various software packages.  So at this point I gave up.


I did go home last night and install the latest wxGTK and wxPython
packages for Linux.  But that's a subject for a separate post...

-- 
Mitch Chapman
chapman at bioreason.com