From 05d61b6996270dfed35546f24569e327d84e260f Mon Sep 17 00:00:00 2001 From: Robin Dunn Date: Thu, 30 May 2002 18:40:57 +0000 Subject: [PATCH] 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 | 68 ++++++++++++++++++++++++++-------------- wxPython/BUILD.unix.txt | 39 +++++++++++------------ wxPython/BUILD.win32.txt | 63 ++++++++++++++++++++----------------- 3 files changed, 98 insertions(+), 72 deletions(-) diff --git a/wxPython/BUILD.osx.txt b/wxPython/BUILD.osx.txt index 159df03fb1..1af6b0d189 100644 --- 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 - 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 - 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 -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 - -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: - 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. --Robin diff --git a/wxPython/BUILD.unix.txt b/wxPython/BUILD.unix.txt index a4f3e1d1e4..8ff5e8047c 100644 --- 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 -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. @@ -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 - 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 diff --git a/wxPython/BUILD.win32.txt b/wxPython/BUILD.win32.txt index 2fe8abf75a..0687e8d53d 100644 --- 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 -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 @@ -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 - 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 - 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 @@ -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: - 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 ** @@ -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 - 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 - 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 @@ -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/. -- 2.47.2