wxPython doc updates
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@3551 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
@@ -122,91 +122,83 @@ for a listing of a few of them.
|
||||
\section{Building wxPython}\label{wxpbuild}
|
||||
|
||||
I used SWIG (\urlref{http://www.swig.org}{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. If you try to build wxPython and get errors
|
||||
because SWIG is missing, then simply touch the .cpp and .py files so
|
||||
make won't attempt to build them from the .i files.
|
||||
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 the patches are in
|
||||
wxPython/SWIG.patches and they should be applied to the 1.1p5 version
|
||||
of SWIG. These new patches are documented at
|
||||
\urlref{this site}{http://starship.skyport.net/crew/robind/python/\#swig},
|
||||
and they should also end up in the 1.2 version of SWIG.
|
||||
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
|
||||
\urlref{http://www.swig.org/}{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 \tt{PYTHONPATH}, (and preferably
|
||||
should be named wxPython.) You can control where the build process
|
||||
will dump wxPython by setting the \tt{TARGETDIR} makefile variable.
|
||||
The default is \tt{\$(WXWIN)/utils/wxPython}. If you leave it here
|
||||
then you should add \tt{\$(WXWIN)/utils} to your \tt{PYTHONPATH}.
|
||||
However, you may prefer to use something that is already on your
|
||||
\tt{PYTHONPATH}, such as the \tt{site-packages} directory on Unix
|
||||
systems.
|
||||
|
||||
\wxheading{Win32}
|
||||
|
||||
These instructions assume that you have Microsoft Visual C++ 5.0 or
|
||||
6.0, that you have installed the command-line tools, and that the
|
||||
appropriate environment variables are set for these tools. You should
|
||||
also have Python 1.5.1 installed, and wxWindows installed and built as
|
||||
specified below.
|
||||
subdirectory of a directory on the \tt{PYTHONPATH}. (And preferably should
|
||||
be named wxPython.) You can control where the build process will dump
|
||||
wxPython by setting the \tt{TARGETDIR} variable for the build utility, (see
|
||||
below.)
|
||||
|
||||
\begin{enumerate}\itemsep=0pt
|
||||
\item Build wxWindows with \tt{wxUSE_RESOURCE_LOADING_IN_MSW} set to 1 in
|
||||
\tt{include/wx/msw/setup.h} so icons can be loaded dynamically. While
|
||||
there, make sure \tt{wxUSE_OWNER_DRAWN} is also set to 1.
|
||||
\item Build wxWindows as described in its BuildCVS.txt file. For *nix
|
||||
systems I run configure with these flags:
|
||||
|
||||
\begin{verbatim}
|
||||
--with-gtk
|
||||
--with-libjpeg
|
||||
--without-odbc
|
||||
--enable-unicode=no
|
||||
--enable-threads=yes
|
||||
--enable-socket=yes
|
||||
--enable-static=no
|
||||
--enable-shared=yes
|
||||
--disable-std_iostreams
|
||||
\end{verbatim}
|
||||
|
||||
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 also. The
|
||||
build utility currently does not support any other win32 compilers.
|
||||
|
||||
\item At this point you may want to make an alias or symlink, script,
|
||||
batch file, whatever on the PATH that invokes
|
||||
\tt{\$(WXWIN)/utils/wxPython/distrib/build.py} to help simplify matters
|
||||
somewhat. For example, on my win32 system I have a file named
|
||||
\tt{build}.bat in a directory on the PATH that contains:
|
||||
|
||||
\tt{python \%WXWIN/utils/wxPython/distrib/build.py \%1 \%2 \%3 \%4 \%5 \%6}
|
||||
|
||||
|
||||
\item Change into the \tt{\$(WXWIN)/utils/wxPython/src} directory.
|
||||
\item Edit makefile.vc and specify where your python installation is at.
|
||||
You may also want to fiddle with the \tt{TARGETDIR} variable as described
|
||||
above.
|
||||
\item Run \tt{nmake -f makefile.vc}
|
||||
\item If it builds successfully, congratulations! Move on to the next
|
||||
step. If not then you can try mailing the wxwin-developers list for
|
||||
help. Also, I will always have a pre-built win32 version of this extension module at
|
||||
\urlref{http://alldunn.com/wxPython}{http://alldunn.com/wxPython}.
|
||||
|
||||
\item Type "\tt{build -b}" to build wxPython and "\tt{build -i}" to
|
||||
install it, or \"\tt{build -bi}\" to do both steps at once.
|
||||
|
||||
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 are
|
||||
able to to override many configuration options in a file named
|
||||
build.local.
|
||||
|
||||
\item To build and install the add-on modules, change to the appropriate
|
||||
directory under \tt{\$(WXWIN)/utils/wxPython/modules} and run the build
|
||||
utility again.
|
||||
|
||||
\item Change to the \tt{\$(WXWIN)/utils/wxPython/demo} directory.
|
||||
\item Try executing the demo program. Note that some of the demos print
|
||||
diagnositc or test info to standard output, so they will require the
|
||||
console version of python. For example:
|
||||
|
||||
\tt{python demo.py}
|
||||
|
||||
To run them without requiring a console, you can use the \tt{pythonw.exe}
|
||||
version of Python either from the command line or from a shortcut.
|
||||
\end{enumerate}
|
||||
|
||||
\wxheading{Unix}
|
||||
|
||||
These directions assume that you have already successfully built
|
||||
wxWindows for GTK, and installed Python 1.5.1 or later. If you build Python
|
||||
yourself, you will get everything installed that you need simply by
|
||||
doing \bftt{make install}. If you get Python from an RPM or other
|
||||
pre-packaged source then there will probably be a separate package
|
||||
with the development libraries, etc. that you will need to install.
|
||||
|
||||
|
||||
\begin{enumerate}\itemsep=0pt
|
||||
\item Change into the \tt{\$(WXWIN)/utils/wxPython/src} directory.
|
||||
\item Edit \tt{Setup.in} and ensure that the flags, directories, and toolkit
|
||||
options are correct, (hopefully this will be done by \tt{configure}
|
||||
soon.) See the above commentary about \tt{TARGETDIR}. There are a
|
||||
few sample Setup.in.[platform] files provided.
|
||||
\item Run this command to generate a makefile:
|
||||
|
||||
\tt{make -f Makefile.pre.in boot}
|
||||
|
||||
\item Once you have the \tt{Makefile}, run \bftt{make} to build and then
|
||||
\bftt{make install} to install the wxPython extension module.
|
||||
\item Change to the \tt{\$(WXWIN)/utils/wxPython/demo} directory.
|
||||
\item Try executing the demo program. For example:
|
||||
|
||||
\tt{python demo.py}
|
||||
\tt{python demo.py}
|
||||
|
||||
To run it without requiring a console on win32, you can use the
|
||||
\tt{pythonw.exe} version of Python either from the command line or from a
|
||||
shortcut.
|
||||
|
||||
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
|
||||
@@ -314,7 +306,7 @@ it by issuing this command:
|
||||
\begin{enumerate}\itemsep=0pt
|
||||
\item At line 2 the wxPython classes, constants, and etc. are imported
|
||||
into the current module's namespace. If you prefer to reduce
|
||||
namespace polution you can use "\tt{from wxPython import wx}" and
|
||||
namespace pollution you can use "\tt{from wxPython import wx}" and
|
||||
then access all the wxPython identifiers through the wx module, for
|
||||
example, "\tt{wx.wxFrame}".
|
||||
\item At line 13 the frame's sizing and moving events are connected to
|
||||
|
Reference in New Issue
Block a user