Python and GUI options

[Robin Dunn]

>
> > Re the other problems.  If build system changes don't do away with it (I
> > hope they do), more docs on creating the build.local file are a must.
>
>  Sorry again, but I don't even know what is it?
>

It's used by the build script (.../utils/wxPython/distrib/build.py) for
wxPython.  I created this so I wouldn't have to maintain two different build
systems for win32 and unix, (and eventually Mac) and the new distutils tools
were not far enough along at the time.


>
> > Also, wxGTK and wxPython sense different
> > compilers (SGI vs. GCC).  I had to coerce them to use the same ones.
>
>  Hmm... How did this happen? Did the value of your CXX env var changed
> in between somehow?
>

The build.py tool tries to figure out what compilers were used to build
Python and uses those.  I've had problems with extension modules before if
there were differences.  I didn't think about similar issues with wxGTK,
maybe if wx-config had some new flags that gave compiler/static
linker/dynamic linker specifications...


Basically, build.py does the following:

1. Discovers whatever it can from Python itself and the environment on the
machine about how Python was built on the system, and how to build Python
extension modules, similar to how the old standard Makefile.pre.in worked.

2. Reads information about what needs built in the current directory from
./build.cfg.

3. Looks for ./build.local, ../build.local, and ../../build.local for
overrides to the default or discovered values.

4. Builds a Makefile that uses `wx-config --cflags` and `wx-config --libs` to
handle wx configuration issues.

5. Based on command line flags runs make, make install, make clean, etc.


--
Robin Dunn
Software Craftsman
robin at AllDunn.com
http://AllDunn.com/robin/
http://AllDunn.com/wxPython/  Check it out!