\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 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 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:
+\item Build wxWindows as described in its BuildCVS.txt file. For *nix
+ systems I run configure with these flags:
-\tt{python demo.py}
+\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}
-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}
+ You can use whatever flags you want, but I know these work.
-\wxheading{Unix}
+ 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.
-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.
+\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}
-\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 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 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}
\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
projects / wxWidgets.git / commitdiff
