Updated wxPython build instructions

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

diff --git a/wxPython/BUILD.osx.txt b/wxPython/BUILD.osx.txt
index 159df03fb19e031f026f9d6c98177185491630f3..1af6b0d1890c1f6da029bcdc2fd1bb44cdf93df5 100644 (file)
--- a/wxPython/BUILD.osx.txt
+++ b/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
 -----------------------------
 
 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
 
 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.
 
 
 get things from various CVS repositories as needed.
 
 

-1. Python 2.2 is required.  Get the source from www.python.org and
-   build Python.app and install it as described in the Mac/OSX/README
-   file.
+1. Python 2.2 is required.  There is a disk image with an installer
+   package in the wxPython Sourceforge download area, in this group:
+
+   http://sourceforge.net/project/showfiles.php?group_id=10718&release_id=84730

 
 

-2. 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:
+   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
 
 
         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
 
 
        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
 
 
         cd build
        ../configure --with-mac --with-opengl --enable-debug
 

-5. Make and install wxMac.
+4. Make and install wxMac.

 
        make
        sudo make install
 
 
        make
        sudo make install
 

-6. Build wxPython for testing (without installing it.)
+5. Build and install wxPython.

 
        cd ../wxPython
 
        cd ../wxPython

-       python setup.py IN_CVS_TREE=1 build_ext --inplace --debug
-
-7. Test.  The easiest way to do this from the CVS tree (witout having
-   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.
+       python setup.py IN_CVS_TREE=1 build install

 
 

-       cd demo
-       ln -s ../wxPython .
-
-8. Now just navigate in the Finder to the demo directory and double
+6. Test.  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:
 
    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
    the patches to me.  <wink>
 
 --Robin

diff --git a/wxPython/BUILD.unix.txt b/wxPython/BUILD.unix.txt
index a4f3e1d1e4db96dfaaf821f678ff5ea5598681d7..8ff5e8047c524d0f5b28f449dd401f243d5c4f53 100644 (file)
--- a/wxPython/BUILD.unix.txt
+++ b/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
 
 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
-you'll want to have version 1.1-883 of SWIG and you'll need to apply
-the patches and updates in wxPython/SWIG and rebuild it.  Then you'll
+need to have SWIG unless you want to modify the *.i files.  I've made
+several modifications to SWIG specific to wxPython's needs and so the
+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.
 
 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/
 
 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...
 
 
 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
 -------------------------------
 
 A. You can find the sources and RPMs for wxGTK at

-   ftp://wesley.informatik.uni-freiburg.de/pub/linux/wxxt/source/, or
-   just follow the download links from http://wxwindows.org/.  You can
-   also check out a current snapshot of the sources from the CVS
-   server.  (Some information about annonymous CVS access is at
-   http://wxwindows.org/cvs.htm.)  The advantage of using CVS is 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
-   method is best for you.
+   http://wxwindows.org/, just follow the download links from the
+   nevigation panel.  You can also check out a current snapshot of the
+   sources from the CVS server.  (Some information about annonymous
+   CVS access is at http://wxwindows.org/cvs.htm.)  The advantage of
+   using CVS is 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 thorough testing done.  You
+   can decide which 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
 
 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

diff --git a/wxPython/BUILD.win32.txt b/wxPython/BUILD.win32.txt
index 2fe8abf75a823e0369293b29f778efa8889615b0..0687e8d53dbed36efbd20a8e0e645db9d0838db4 100644 (file)
--- a/wxPython/BUILD.win32.txt
+++ b/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
 
 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
-you'll want to have version 1.1-883 of SWIG and you'll need to apply
-the patches and updates in wxPython/SWIG and rebuild it.  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.
+need to have SWIG unless you want to modify the *.i files.  I've made
+several modifications to SWIG specific to wxPython's needs and so the
+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:
+
+      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
 
 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
 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
-   http://wxwindows.org/cvs.htm.)  The advantage of using CVS is that
-   you can easily update as soon as the developers check in new
+   information about annonymous CVS access is at the
+   http://wxwindows.org/cvs.htm site.)  The advantage of using CVS is
+   that you can easily update as soon as the developers check in new

    sources or fixes.  The advantage of using a released version is
    sources or fixes.  The advantage of using a released version is

-   that it usually has had more testing done.  You can decide which
-   method is best for you.
+   that it usually has had more thorough testing done.  You can decide
+   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
 
 B. You'll usually want to use wxWindows sources that have the same
    version number as the wxPython sources you are using.  (Another


@@ -76,14 +81,14 @@ 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:
 
    the default setup0.h in my setup.h, but you can experiment with
    other settings if you like:
 

-         wxDIALOG_UNIT_COMPATIBILITY   0
-         wxUSE_GLOBAL_MEMORY_OPERATORS 0
-         wxUSE_DEBUG_NEW_ALWAYS        0
-         wxUSE_CMDLINE_PARSER          0
-         wxUSE_DIALUP_MANAGER          0
-         wxUSE_DYNAMIC_LOADER          0
-         wxUSE_TREELAYOUT              0
-         wxUSE_POSTSCRIPT              1
+        WXWIN_COMPATIBILITY_2_2        0
+         wxDIALOG_UNIT_COMPATIBILITY   0
+        wxUSE_MEMORY_TRACING           1
+         wxUSE_CMDLINE_PARSER          0
+        wxUSE_FSVOLUME                 0
+         wxUSE_DIALUP_MANAGER          0
+         wxUSE_TREELAYOUT              0
+         wxUSE_POSTSCRIPT              1

 
 
     ** NEW **
 
 
     ** NEW **


@@ -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.
 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
-   sources to get the HYBRID capability.)  Here are some more details:
+   Here are some more details:

 
       DEBUG Specified with "FINAL=0" and produces a DLL named
 
       DEBUG Specified with "FINAL=0" and produces a DLL named

-            wx[version]d.dll.  This DLL is compiled with full
-            debugging information and with the __WXDEBUG__ set which
-            enables some debugging-only code in wxWindows such as
-            assertions and failure log messages.  The /MDd flag is
+            wxmsw[version]d.dll.  This DLL is compiled with full
+            debugging information and with the __WXDEBUG__ macro set,
+            which enables some debugging-only code in wxWindows such
+            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
             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
             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
             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
             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
             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
    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):
 
 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
 -----------------------------
 
 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/.
 
    are all set, otherwise you need to download and install Distutils
    1.0 from http://www.python.org/sigs/distutils-sig/.