Updated wxPython build instructions

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

wxPython/BUILD.osx.txt

@@ -2,7 +2,11 @@ Building wxPython on Mac OS X
 -----------------------------
 
 NOTE:  OS X support is HIGHLY EXPERIMENTAL at this time.  Most things
-       don't work correctly (or at all) yet.
+       are working now, but a few still don't.  I know about most of
+       them and am addressing them as I have time.  If you have any
+       ideas about a fix for the stuff that's still broken then
+       please persue them and send the fixes to me.
+
 
 These are the steps I have used for building wxPython on Mac OS X 10.1
 with the Apple Developer Tools, a.k.a the Darwin version.  I assume
@@ -10,53 +14,71 @@ that you know your way around a command line and that you know how to
 get things from various CVS repositories as needed.
 
 
-1. Python 2.2 is required.  Get the source from www.python.org and
+1. Python 2.2 is required.  There is a disk image with an installer
-   build Python.app and install it as described in the Mac/OSX/README
+   package in the wxPython Sourceforge download area, in this group:
-   file.
 
-2. You may want to make a symlink or two in /usr/local/bin so that
+   http://sourceforge.net/project/showfiles.php?group_id=10718&release_id=84730
-   this version of Python can be found from the command line.  For
+
-   example:
+   If, for some reason you need to build your own Python, get the
+   source from www.python.org and follow theinstructions in the
+   Mac/OSX/README file to build and install Python.app and the
+   Python.framework.
+
+   If you build your own Python then you may want to make a symlink or
+   two in /usr/local/bin so that this version of Python can be found
+   from the command line.  For example:
 
         cd /usr/local/bin
 	sudo ln -s /Library/Frameworks/Python.framework/Versions/2.2/bin/python2.2 python2.2
         sudo ln -s python2.2 python
 
-3. In a wxWindows CVS tree make a build directory.
+   Also, if you create a /usr/local/bin/pythonw script like the
+   following then you can run Python GUI apps (like wxPython) directly
+   from the command line:
+
+       #!/bin/sh
+       exec /Applications/Python.app/Contents/MacOS/python $@
+
+   Be sure to give this script execute permissions:
+
+       sudo chmod +x /usr/local/bin/pythonw
+
+   If you would like to make a MachoPython installer from what you
+   built then you may want to look at the scripts I use to do it
+   located in wxPython/distrib/mac/buildPython.
+
+   One last thing, make sure that /usr/local/bin is in your PATH
+   environment variable.
+
+
+2. In a wxWindows CVS tree make a build directory.
 
 	cd ~/proj/wxWindows	# or wherever you put it
 	mkdir build
 
-4. Run configure from that build directory.
+3. Run configure from that build directory.
 
         cd build
 	../configure --with-mac --with-opengl --enable-debug
 
-5. Make and install wxMac.
+4. Make and install wxMac.
 
 	make
 	sudo make install
 
-6. Build wxPython for testing (without installing it.)
+5. Build and install wxPython.
 
 	cd ../wxPython
-	python setup.py IN_CVS_TREE=1 build_ext --inplace --debug
+	python setup.py IN_CVS_TREE=1 build install
 
-7. Test.  The easiest way to do this from the CVS tree (witout having
+6. Test.  Just navigate in the Finder to the demo directory and double
-   to reinstall after every build) is to make a symlink in the demo
-   directory to the wxPython package dir, and then run stuff directly
-   from the demo.
-
-	cd demo
-	ln -s ../wxPython .
-
-8. Now just navigate in the Finder to the demo directory and double
    click demo.py, or simple.py, or whatever you want to run.  Or from
    a command line you can run it this way:
 
-        open -a Python demo.py
+	cd demo
+	pythonw demo.py
 
-9. Figure out what's wrong, figure out how to fix it, and then send
+7. Figure out what's wrong, figure out how to fix it, and then send
    the patches to me.  <wink>
 
 --Robin

wxPython/BUILD.unix.txt

@@ -13,9 +13,16 @@ few bits of background information on tools.
 
 I use a tool called SWIG (http://www.swig.org) to help generate the
 C++ sources used in the wxPython extension module.  However you don't
-need to have SWIG unless you want to modify the *.i files.  If you do
+need to have SWIG unless you want to modify the *.i files.  I've made
-you'll want to have version 1.1-883 of SWIG and you'll need to apply
+several modifications to SWIG specific to wxPython's needs and so the
-the patches and updates in wxPython/SWIG and rebuild it.  Then you'll
+modified sources are included in the wx CVS at .../wxPython/wxSWIG.
+If you need to modify the *.i files for wxPython then change to this
+directory and run:
+
+      configure
+      make
+
+(Do not run "make install" as wxswig is run in-place.)  You'll then
 need to change a flag in the setup.py script as described below so the
 wxPython build process will use SWIG if needed.
 
@@ -24,15 +31,6 @@ with Python 2.0, but if you want to use Python 1.5.2 or 1.6 then
 you'll need to download and install Distutils 1.0 from
 http://www.python.org/sigs/distutils-sig/
 
-I usually use RedHat Linux when working on the wxGTK version of
-wxPython, but I occasionally build and test on Solaris and I hope to
-be able to add some other platforms soon.  The compiler I use is
-whatever comes with the current version of RedHat I am using.  I find
-that there are less portability problems with the RPMs if I don't try
-using the latest and greatest compilers all the time.  On the other
-platforms I usually stick with as recent a version of GCC that I can
-find pre-built for that platform.
-
 Okay, now on the the fun stuff...
 
 
@@ -78,15 +76,14 @@ C. If all else fails, you can get the source code for glib and gtk+ at
 -------------------------------
 
 A. You can find the sources and RPMs for wxGTK at
-   ftp://wesley.informatik.uni-freiburg.de/pub/linux/wxxt/source/, or
+   http://wxwindows.org/, just follow the download links from the
-   just follow the download links from http://wxwindows.org/.  You can
+   nevigation panel.  You can also check out a current snapshot of the
-   also check out a current snapshot of the sources from the CVS
+   sources from the CVS server.  (Some information about annonymous
-   server.  (Some information about annonymous CVS access is at
+   CVS access is at http://wxwindows.org/cvs.htm.)  The advantage of
-   http://wxwindows.org/cvs.htm.)  The advantage of using CVS is that
+   using CVS is that you can easily update as soon as the developers
-   you can easily update as soon as the developers check in new
+   check in new sources or fixes.  The advantage of using a released
-   sources or fixes.  The advantage of using a released version is
+   version is that it usually has had more thorough testing done.  You
-   that it usually has had more testing done.  You can decide which
+   can decide which method is best for you.
-   method is best for you.
 
 B. You'll usually want to use a version of wxGTK that has the same
    version number as the wxPython sources you are using.  (Another

wxPython/BUILD.win32.txt

@@ -18,11 +18,16 @@ few bits of background information on tools.
 
 I use a tool called SWIG (http://www.swig.org) to help generate the
 C++ sources used in the wxPython extension module.  However you don't
-need to have SWIG unless you want to modify the *.i files.  If you do
+need to have SWIG unless you want to modify the *.i files.  I've made
-you'll want to have version 1.1-883 of SWIG and you'll need to apply
+several modifications to SWIG specific to wxPython's needs and so the
-the patches and updates in wxPython/SWIG and rebuild it.  Then you'll
+modified sources are included in the wx CVS at .../wxPython/wxSWIG.
-need to change a flag in the setup.py script as described below so the
+If you need to modify the *.i files for wxPython then change to this
-wxPython build process will use SWIG if needed.
+directory and run:
+
+      nmake -f makefile.vc
+
+Then you'll need to change a flag in the setup.py script as described
+below so the wxPython build process will use SWIG if needed.
 
 I use the new Python Distutils tool to build wxPython.  It is included
 with Python 2.0, but if you want to use Python 1.5.2 or 1.6 then
@@ -46,12 +51,12 @@ And now on to the fun stuff...
 A. There are a few possible ways to get sources for wxWindows.  You
    can download a released version from http://wxwindows.org/ or you
    can get current development sources from the CVS server.  (Some
-   information about annonymous CVS access is at
+   information about annonymous CVS access is at the
-   http://wxwindows.org/cvs.htm.)  The advantage of using CVS is that
+   http://wxwindows.org/cvs.htm site.)  The advantage of using CVS is
-   you can easily update as soon as the developers check in new
+   that you can easily update as soon as the developers check in new
    sources or fixes.  The advantage of using a released version is
-   that it usually has had more testing done.  You can decide which
+   that it usually has had more thorough testing done.  You can decide
-   method is best for you.
+   which method is best for you.
 
 B. You'll usually want to use wxWindows sources that have the same
    version number as the wxPython sources you are using.  (Another
@@ -76,12 +81,12 @@ D. Change to the wx2\include\wx\msw directory and copy setup0.h to
    the default setup0.h in my setup.h, but you can experiment with
    other settings if you like:
 
+	 WXWIN_COMPATIBILITY_2_2	0
          wxDIALOG_UNIT_COMPATIBILITY	0
-         wxUSE_GLOBAL_MEMORY_OPERATORS 0
+	 wxUSE_MEMORY_TRACING		1
-         wxUSE_DEBUG_NEW_ALWAYS        0
          wxUSE_CMDLINE_PARSER		0
+	 wxUSE_FSVOLUME			0
          wxUSE_DIALUP_MANAGER		0
-         wxUSE_DYNAMIC_LOADER          0
          wxUSE_TREELAYOUT		0
          wxUSE_POSTSCRIPT		1
 
@@ -106,14 +111,13 @@ A. Although MSVC project files are provided I always use the makefiles
 B. There are three different types of wxWindows DLLs that can be
    produced by the VC makefile simply by providing a flag on the nmake
    command-line, I call the three types DEBUG, FINAL, and HYBRID.
-   (The last one is brand new, you'll need my version of the 2.2.2
+   Here are some more details:
-   sources to get the HYBRID capability.)  Here are some more details:
 
       DEBUG Specified with "FINAL=0" and produces a DLL named
-            wx[version]d.dll.  This DLL is compiled with full
+            wxmsw[version]d.dll.  This DLL is compiled with full
-            debugging information and with the __WXDEBUG__ set which
+            debugging information and with the __WXDEBUG__ macro set,
-            enables some debugging-only code in wxWindows such as
+            which enables some debugging-only code in wxWindows such
-            assertions and failure log messages.  The /MDd flag is
+            as assertions and failure log messages.  The /MDd flag is
             used which means that it is linked with the debugging
             version of the C runtime library and also that you must
             use the debugging version of Python, (python_d.exe and
@@ -124,7 +128,7 @@ B. There are three different types of wxWindows DLLs that can be
             wxPython extension and the wxWindows DLL.
 
       FINAL Specified with "FINAL=1" and produces a DLL named
-            wx[version].dll.  This DLL is compiled with optimizations
+            wxmsw[version].dll.  This DLL is compiled with optimizations
             turned on and without debugging information and without
             __WXDEBUG__.  The /MD flag is used which means that you
             can use this version with the standard python.exe.  This
@@ -132,7 +136,7 @@ B. There are three different types of wxWindows DLLs that can be
             for win32.
 
      HYBRID Specified with "FINAL=hybrid" and produces a DLL named
-            wx[version]h.dll.  This DLL is almost the same as the
+            wxmsw[version]h.dll.  This DLL is almost the same as the
             DEBUG version except the /MD flag is used which means that
             you can use the standard python.exe but you still get the
             debugging info and the __WXDEBUG__ code enabled.  With the
@@ -157,7 +161,10 @@ C. Change to the wx2\src\msw directory and type the following command,
    DLL and some library files in \wx2\lib.
 
 D. You'll either need to add \wx2\lib to the PATH or copy the DLL file
-   to a directory already on the PATH so the DLL can be found at runtime.
+   to a directory already on the PATH so the DLL can be found at
+   runtime.  Another option is to copy the DLL to the directory that
+   the wxPython pacakge is installed to, for example,
+   c:\Python22\lib\site-packages\wxPython.
 
 E. You can test your build by changing to one of the directories under
    \wx2\samples or \wx2\demos and typing (using the right FINAL flag):
@@ -185,7 +192,7 @@ A. You have the same options (and same advantages/disadvantages) for
 -----------------------------
 
 A. As mentioned previouslly, wxPython is built with the standard
-   Python Distutils tool.  If you are using Python 2.0c1 or later you
+   Python Distutils tool.  If you are using Python 2.0 or later you
    are all set, otherwise you need to download and install Distutils
    1.0 from http://www.python.org/sigs/distutils-sig/.