--- /dev/null
+Build Instructions
+------------------
+I used SWIG (http://www.swig.org) to create the source code for the
+extension module. This enabled me to only have to deal with a small
+amount of code and only have to bother with the exceptional issues.
+SWIG takes care of the rest and generates all the repetative code for
+me. You don't need SWIG to build the extension module as all the
+generated C++ code is included under the src directory.
+
+I added a few minor features to SWIG to control some of the code
+generation. If you want to play around with this you will need to get
+a recent version of SWIG from their CVS or from a daily build. See
+http://www.swig.org/ for details.
+
+wxPython is organized as a Python package. This means that the
+directory containing the results of the build process should be a
+subdirectory of a directory on the PYTHONPATH. (And preferably should
+be named wxPython.) You can control where the build process will dump
+wxPython by setting the TARGETDIR variable for the build utility, (see
+below.)
+
+
+1. Build and install wxWindows as described in its BuildCVS.txt or
+ INSTALL.txt file. For *nix systems I run configure with these
+ flags:
+
+ --with-gtk
+ --with-libjpeg
+ --without-odbc
+ --enable-unicode=no
+ --enable-threads=yes
+ --enable-socket=yes
+ --enable-static=no
+ --enable-shared=yes
+ --disable-std_iostreams
+
+ You can use whatever flags you want, but these work for me.
+
+ For Win32 systems I use Visual C++ 6.0, but 5.0 should work. The
+ build utility currently does not support any other win32
+ compilers. Be sure to copy include/wx/msw/setup0.h to
+ include/wx/msw/setup.h and edit it for the options you want.
+
+
+2. For either platform, you should be sure to set an environment
+ variable named WXWIN to be the path to the top of the wxWindows
+ tree.
+
+3. If you are working from a copy of the code retrieved from CVS, then
+ you will find wxPython in $WXWIN/utils/wxPython. If you are
+ working from the tar.gz or .zip files then you will probably want
+ to unpack wxPython in the $WXWIN/utils directory and rename the new
+ directory to wxPython (or use a symlink.) If you want to keep it
+ in a separate directory then you can change where the build.py tool
+ expects to find it by creating a file named build.local (see step 6
+ for more examples about build.local,) containing something like
+ this:
+
+ WXPSRCDIR = "~/MyStuff/wxPython-2.1.11/src"
+
+
+4. At this point you may want to make an alias or symlink, script,
+ batch file, whatever on the PATH that invokes
+ $WXWIN/utils/wxPython/distrib/build.py to help simplify matters
+ somewhat. For example, on my win32 system I have a file named
+ build.bat in a directory on the PATH that contains:
+
+ python %WXWIN%/utils/wxPython/distrib/build.py %1 %2 %3 %4 %5 %6
+
+
+5. Change into the $(WXWIN)/utils/wxPython/src directory.
+
+
+6. Type "build -b" to build wxPython and "build -i" to install it.
+
+ The build.py script actually generates a Makefile based on what it
+ finds on your system and information found in the build.cfg file.
+ If you have troubles building or you want it built or installed in
+ a different way, take a look at the docstring in build.py. You may
+ be able to override configuration options in a file named
+ build.local. For example, you can set a new TARGETDIR just by
+ creating a file named build.local in your wxPython source directory
+ and assign a value to it, like this:
+
+ TARGETDIR = "/usr/local/lib/python1.5/site-packages/wxPython"
+
+ The build.local file is executed as Python code so you can do very
+ creative things there if you need to.
+
+
+7. To build and install the add-on modules, change to the appropriate
+ directory under $WXWIN/utils/wxPython/modules and run the build
+ utility again.
+
+
+8. Change to the $WXWIN/utils/wxPython/demo directory.
+
+
+9. Try executing the demo program. For example:
+
+ python demo.py
+
+To run it without requiring a console on win32, you can use the
+pythonw.exe version of Python either from the command line or from a
+shortcut.
+
+
What's new in 2.1.12
--------------------
-Updated wxMVCTree and added a demo for it.
+Updated wxMVCTree and added a demo for it, also fixed layout on GTK
+and some flicker problems.
Added a wrapper class for the Visualization ToolKit (or VTK) in the
wxPython.lib.vtk module. (http://www.kitware.com/)
Added wxPython.lib.spashscreen from Mike Fletcher.
+Added wxPython.lib.filebrowsebutton also from Mike Fletcher.
+
-Build Instructions
-------------------
-I used SWIG (http://www.swig.org) to create the source code for the
-extension module. This enabled me to only have to deal with a small
-amount of code and only have to bother with the exceptional issues.
-SWIG takes care of the rest and generates all the repetative code for
-me. You don't need SWIG to build the extension module as all the
-generated C++ code is included under the src directory.
-
-I added a few minor features to SWIG to control some of the code
-generation. If you want to play around with this you will need to get
-a recent version of SWIG from their CVS or from a daily build. See
-http://www.swig.org/ for details.
-
-wxPython is organized as a Python package. This means that the
-directory containing the results of the build process should be a
-subdirectory of a directory on the PYTHONPATH. (And preferably should
-be named wxPython.) You can control where the build process will dump
-wxPython by setting the TARGETDIR variable for the build utility, (see
-below.)
-
-
-1. Build wxWindows as described in its BuildCVS.txt file. For *nix
- systems I run configure with these flags:
-
- --with-gtk
- --with-libjpeg
- --without-odbc
- --enable-unicode=no
- --enable-threads=yes
- --enable-socket=yes
- --enable-static=no
- --enable-shared=yes
- --disable-std_iostreams
-
- You can use whatever flags you want, but I know these work.
-
- For Win32 systems I use Visual C++ 6.0, but 5.0 should work. The
- build utility currently does not support any other win32 compilers.
-
-2. At this point you may want to make an alias or symlink, script,
- batch file, whatever on the PATH that invokes
- $(WXWIN)/utils/wxPython/distrib/build.py to help simplify matters
- somewhat. For example, on my win32 system I have a file named
- build.bat in a directory on the PATH that contains:
-
- python $(WXWIN)/utils/wxPython/distrib/build.py %1 %2 %3 %4 %5 %6
-
-
-3. Change into the $(WXWIN)/utils/wxPython/src directory.
-
-4. Type "build -b" to build wxPython and "build -i" to install it.
-
- The build.py script actually generates a Makefile based on what it
- finds on your system and information found in the build.cfg file.
- If you have troubles building or you want it built or installed in
- a different way, take a look at the docstring in build.py. You may
- be able to override configuration options in a file named
- build.local.
-
-5. To build and install the add-on modules, change to the appropriate
- directory under $(WXWIN)/utils/wxPython/modules and run the build
- utility again.
-
-6. Change to the $(WXWIN)/utils/wxPython/demo directory.
-
-7. Try executing the demo program. For example:
-
- python demo.py
-
-To run it without requiring a console on win32, you can use the
-pythonw.exe version of Python either from the command line or from a
-shortcut.
-
-
----------------
Robin Dunn
projects / wxWidgets.git / commitdiff
