wxPython doc updates

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@3551 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

docs/latex/wx/wxPython.tex

@@ -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