wxPython Build Notes
If you are working on wxPython, or otherwise have a need to build your own copy of wxPython, the two following methods are recommended by Robin:
Note 1: You can get the OSAF wxPython source from two locations - one is by letting
external/wx/Makefile
export the last known stable version or by creating a OSAF wx repository working directory of its trunk. Either will work with the below directions. The OSAF wx subversion repository is located at
svn+ssh://svn.osafoundation.org/svn/wx/trunk
or
http://svn.osafoundation.org/wx/trunk/
.
Note 2: When wxPython is built directly from wx repository working directory the version number is changed to reflect that it is an "interim" build instead of a last known stable verison built from
external/wx
. The interim build version number will look something like
"2.7.0.0-r57-interim"
. This will enable you to more easily tell which version of wxPython you are currently using, for example in Chandler you can go to the Test menu and open a PyShell and look at its About menu item where the wxPython version is listed.
Note 3: You need to make sure the build environment is prepared for building wx. This includes having swig and python be available - to ensure this, you can use the
"to-python"
build target to build everything python requires.
Note 4: You will see references to
"DEBUG=1"
in the build steps. There are two versions of Chandler you can build: the "release" version, and the "debug" version. Typically end users will use "release" versions of Chandler. The "debug" version is only used when a developer (or savvvy user) wishes to track down and/or reproduce a problem. If you want to build a "debug" version of Chandler, all invocations of
"make"
must include
DEBUG=1
in the list of arguments. Note that mixing and matching will not work.
Symlink method
By symlinking
external/[debug|release]
to
chandler/[debug|release]
then the output of running make in
wx/
will go straight to chandler's runtime directories instead of needing additional steps to build the tarball and install it. This can also work on Windows by using the junction tool from sysinternals.com to make the directory links.
When using this approach these are the steps to take:
- Make sure
BUILD_ROOT
is set to the external/
directory you're working from
- Make the symlinks in external to point to chandler's directories
-
ln -s chandler/release external/release
-
ln -s chandler/debug external/debug
(if you're doing a debug build)
- Go to
chandler
and run "make install"
to get all the binaries
- Just to be safe you may want to clean out the wx files installed by Chandler's
"make install"
. To do this, Go to chandler
and run "make cleaninstalldir"
- Go to
external/swig
and run "make"
(or "make DEBUG=1" for a debug build) to get a swig binary built and installed.
- Go to the
wx
source tree and run "make"
(or "make DEBUG=1" for a debug build) and if the build succeeds all of the wxWidgets and wxPython files will be installed in chandler/release
or chandler/debug
.
- Go to the chandler directory and test.
Non-symlink method
- Make sure
BUILD_ROOT
is set to the external/
directory you're working from
- Go to
external
and run "make realclean"
(or make DEBUG=1 realclean)
- In
external
run "make to-python"
(or make DEBUG=1 to-python)
- Go to
external/python
and run "make"
(or make DEBUG=1) to put a copy of Python in external/[release|debug]
- Go to
external/swig
and run "make"
(or make DEBUG=1) to put a copy of SWIG in external/[release|debug]
- Go to
chandler
and run "make install"
(or make DEBUG=1 install) to get the other binaries. See note above about cleaning up wx files installed the normal way...
- Go to the wx source tree and run
"make realclean"
(or make DEBUG=1 realclean)
- In wx, run
"make build snap drop"
(or make DEBUG=1 build snap drop) to build wx, build a tarball and untar the tarball in chandler's directories.
- Go to the chandler directory and test.