Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Split build instructions into a separate file.

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@4683 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Robin Dunn
1999-11-25 07:12:34 +00:00
parent 694759cfeb
commit 41509312d6
2 changed files with 111 additions and 76 deletions
Download Patch File Download Diff File Expand all files Collapse all files

107
utils/wxPython/BUILD.txt Normal file
View File

@@ -0,0 +1,107 @@
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.

80
utils/wxPython/README.txt
View File

@@ -47,7 +47,8 @@ Or you can send mail directly to the list using this address:
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/)
@@ -57,6 +58,8 @@ Fixed wxTreeCtrl.SetItemImage and GetItemImage to recognise the new
Added wxPython.lib.spashscreen from Mike Fletcher.
Added wxPython.lib.filebrowsebutton also from Mike Fletcher.
@@ -530,81 +533,6 @@ version segfault shortly after starting up.
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