diff --git a/wxPython/distrib/README.1st.txt b/wxPython/distrib/README.1st.txt index ba13d95633..fe2c4ab6fd 100644 --- a/wxPython/distrib/README.1st.txt +++ b/wxPython/distrib/README.1st.txt @@ -1,140 +1,57 @@ -README for wxPythonSrc-*.tar.gz -------------------------------- - -Prior to version 2.3.3 of wxPython I had always made my Linux/Unix -binaries based on the released binary of wxGTK and wxGTK-gl. This -imposed a few restrictions and so starting with 2.3.3 I have decided -to do a combined binary that inlcudes wxGTK as well as wxPython. This -allows me a bit more flexibility and is consistent with how the -Windows and Mac OS X binaries are built. - -If you are reading this file then you are probably interested in -building your own copy of wxPython from the sources contained in this -archive. If you wish to use the released wxGTK binary as has been -done in the past then you can still follow the old build directions in -wxPython/BUILD.unix.txt. If you are building for Windows or Mac OS X -then you should look at wxPython/BUILD.win32.txt or -wxPython/BUILD.osx.txt respectivly. - -If, on the other hand, you would like to build Linux/Unix binaries -with a private copy of wxGTK like what I am now distributing then -you'll want to follow the instructions in this file. (You should -probably still read wxPython/BUILD.unix.txt though since there are -other details there that you may need to be aware of. - -Clear as mud? Good. Let's get started. +README for wxPythonSrc-2.5.*.tar.gz +=================================== -1. We'll be making a private copy of wxGTK so it doesn't conflict with - one used by wxGTK C++ apps that expect to have the default binary - installed from RPM or whatever. I put it in /usr/lib/wxPython, but - you can use whatever you like. I'll just set a variable to our wx - prefix to reference later: +This archive contains the source code and other files for both +wxWindows and wxPython. Some things not needed for the build (such as +the wxWindows samples and docs) have been removed in order to minimize +the size of the archive. If you would like to have the complete set +of sources and etc. then please either use a CVS snapshot from +http://wxwindows.org/snapshots/ or do a checkout from CVS yourself +(see http://www.wxwindows.org/cvs.htm.) If you would like to use CVS +to get the exact same sources as one of these tarballs then you can +update using a release tag. For example:: - export WXPREF=/usr/lib/wxPython + cvs update -r wxPy_2_5_1_0 -2. Make a build directory and configure wxGTK. +For more details about building and installing wxWindows and wxPython +please see these files:: - cd wxPythonSrc-2.4.0 # or whatever the top-level dir is - mkdir build - cd build - ../configure --with-gtk \ - --prefix=$WXPREF \ - --enable-rpath=$WXPREF/lib \ - --with-opengl \ - --enable-geometry \ - --enable-optimise \ - --enable-debug_flag \ - - You may want to use --enable-debug instead of --enable-optimise if - you need to run though a debugger and want full debugging symbols. - - SOLARIS NOTE: The --enable-rpath option may cause problems when - using wxGTK on Solaris when compiling wxPython in step 4 below. - The woraround is to not use --enable-rpath flag for configure, but - in that case all wxPython applications must have the - LD_LIBRARY_PATH set to include $WXPREF/lib, or you can use the - 'crle' program to modify the runtime linking environment. If this - is the only installation of wxGTK on the system then you can use a - system library path for WXPREF and not have to worry about it at - all. - - If you want to use the image and zlib libraries included with - wxWindows instead of those already installed on your system, (for - example, to reduce dependencies on 3rd party libraries) then you - can add these flags to the configure command: - - --with-libjpeg=builtin \ - --with-libpng=builtin \ - --with-libtiff=builtin \ - --with-zlib=builtin \ - - If you would like to use GTK 2.x and unicode, then add the - following flags. Please note that this is still considered beta, - but does look and work quite nice for the most part: - - --enable-gtk2 \ - --enable-unicode \ + wxPython/docs/BUILD.txt + wxPython/docs/INSTALL.txt -3. Build and install wxGTK. (You may need to be root for the last - step, depending on where your WXPREF is.) +For a log of recent changes check these files:: - make - make install + docs/changes.txt (for wxWindows) + wxPython/docs/CHANGES.txt (for wxPython) -4. Build and install wxPython. If you want to use a different version - of Python than is found by default on the PATH then specify the - whole pathname in these steps. The version of Python that runs - setup.py is the version wxPython will be built and installed for. - (You will need to be root for the install step unless your Python - is not in a system location.) +And for information about major changes in wxPython 2.5 and how to +migrate your existing code to 2.5 please read this file:: - cd ../wxPython - python setup.py \ - WX_CONFIG=$WXPREF/bin/wx-config \ - build install - - If you are using GTK 2.x and unicode then do it this way instead: - - python setup.py \ - WX_CONFIG=$WXPREF/bin/wx-config \ - WXPORT=gtk2 UNICODE=1 \ - build install - - If you get errors about wxGLCanvas or being unable to find libGLU - or something like that then you can add BUILD_GLCANVAS=0 to the - setup.py command line to disable the building of the glcanvas - module. - - If you would like to install to some place besides the Python - site-packages directory (such as to your home directory) then you - can add "--root=" after the "install" command. To use - wxPython like this you'll need to ensure that the directory - containing wxPython is contained in the PYTHONPATH environment - variable. + wxPython/docs/MigrationGuide.txt -5. If you havn't already, get a new copy of the demo and documentation - to go with the wxPython you just built and installed. See - http://wxpython.org/download.php#documentation +Further information can be found on the wxWindows and wxPython web +sites and wikis:: + + http://www.wxwindows.org/ + http://wiki.wxwindows.org/ + + http://www.wxpython.org/ + http://wiki.wxpython.org/ -6. Change to the demo directory and run it like this: +And be sure to direct your questions to one of the various mail +lists:: - python demo.py + http://www.wxpython.org/maillist.php - SOLARIS NOTE: If you get unresolved symbol errors when importing - wxPython and you are running on Solaris and building with gcc, then - you may be able to work around the problem by uncommenting a bit of - code in setup.py and building again. Look for 'SunOS' in setup.py - and uncomment the block containing it. The problem is that Sun's ld - does not automatically add libgcc to the link step. -7. That's all, except for the having fun part! +Have fun! -- diff --git a/wxPython/docs/BUILD.osx.txt b/wxPython/docs/BUILD.osx.txt deleted file mode 100644 index 38e72ceb5c..0000000000 --- a/wxPython/docs/BUILD.osx.txt +++ /dev/null @@ -1,80 +0,0 @@ -Building wxPython on Mac OS X ------------------------------ - - -These are the steps I have used for building wxPython on Mac OS X 10.x -with the Apple Developer Tools, a.k.a the Darwin version. I assume -that you know your way around a command line and that you know how to -get things from various CVS repositories as needed. - - -1. "MacPython-OSX" 2.3 is required. If you don't have it already there is a disk image with an - installer package at - - http://homepages.cwi.nl/~jack/macpython/download.html - - If, for some reason you need to build your own Python, get the - source from www.python.org and follow the instructions in the - Mac/OSX/README file to build and install the Python.framework and - Python tools. - - One last thing, make sure that /usr/local/bin is in your PATH - environment variable since that is where the new python and pythonw - commands will be located. - - -2. In a wxWindows CVS tree make a build directory. (You can also use - a CVS snapshot located in http://wxwindows.org/snapshots/ or the - released wxPythonSrc-*.tr.gz archive.) - - cd ~/proj/wxWindows # or wherever you put it - mkdir build - -3. Run configure from that build directory. - - cd build - ../configure --with-mac \ - --with-opengl \ - --enable-geometry \ - --enable-optimise \ - --with-libjpeg=builtin \ - --with-libpng=builtin \ - --with-libtiff=builtin \ - - If you want to add code that activates various runtime checks and - assertion exceptions then add --enable-debug_flag. - -4. Make and install wxMac. - - make - sudo make install - -5. Build and install wxPython. - - cd ../wxPython - python setup.py build install - - If you would like to install to someplace besides the Python - site-packages directory (such as to your home directory) then you - can add "--root=" after the "install" command. To use - wxPython like this you'll need to ensure that the directory - containing wxPyrthon is contained in in the PYTHONPATH environment - variable. - -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: - - cd demo - pythonw demo.py - -7. Figure out what's wrong, figure out how to fix it, and then send - the patches to me. - ---Robin - - - - - - diff --git a/wxPython/docs/BUILD.devel.txt b/wxPython/docs/BUILD.txt similarity index 56% rename from wxPython/docs/BUILD.devel.txt rename to wxPython/docs/BUILD.txt index 262ea0bbee..fb78c5c483 100644 --- a/wxPython/docs/BUILD.devel.txt +++ b/wxPython/docs/BUILD.txt @@ -4,16 +4,29 @@ Building wxPython 2.5 for Development and Testing This file describes how I build wxWindows and wxPython while doing development and testing, and is meant to help other people that want to do the same thing. I'll assume that you are using either a CVS -snapshot or a checkout from CVS. I'll also assume that you know what -you are doing and so I may not be as detailed here as I am in other -BUILD docs. +snapshot from http://wxwindows.org/snapshots/, a checkout from CVS, or +one of the released wxPythonSrc-2.5.* tarballs. I'll also assume that +you know your way around your system, the compiler, etc. and that you +know what you are doing! ;-) -If you want to make changes to any of the *.i files, or regenerate the -extension sources or renamer modules, then you will need an up to date -version of SWIG. Either get and build the current CVS version, or -version 1.3.20 when it is released. If you install this build of SWIG -to a location that is not on the PATH (so it doesn't interfere with an -existing SWIG install for example) then you can set a setup.py +If you want to also install the version of wxPython you build to be in +your site-packages dir and be your default version of wxPython, then a +few additional steps are needed, and you may want to use slightly +different options. See INSTALL.txt for more details. If you only use +the instructions in this BUILD.txt file then you will end up with a +separate installation of wxPython and you can switch back and forth +between this and the release version that you may already have +installed. + +If you want to make changes to any of the *.i files, (SWIG interface +definition files,) or to regenerate the extension sources or renamer +modules, then you will need an up to date version of SWIG. Either get +and build the current CVS version, or version 1.3.20, and then apply +the patches in wxPython/SWIG. See the README.txt in that dir for +details about each patch and also info about those that may already +have been applied to the SWIG sources. If you install this build of +SWIG to a location that is not on the PATH (so it doesn't interfere +with an existing SWIG install for example) then you can set a setup.py command-line variable named SWIG to be the full path name of the executable and the wxPython build will use it. See below for an example. @@ -21,10 +34,10 @@ example. -Building on Linux and OS X --------------------------- +Building on Unix-like Systems (e.g. Linux and OS X) +--------------------------------------------------- -These two platforms are built almost the same way while in development +These platforms are built almost the same way while in development so I'll combine the descriptions about their build process here. First we will build wxWindows and install it to an out of the way place, then do the same for wxPython. @@ -45,27 +58,42 @@ place, then do the same for wxPython. --with-opengl \ --disable-monolithic \ --enable-debug \ - --enable-geometry + --enable-geometry \ On OS X of course you'll want to use --with-mac instead of --with-gtk. For GTK2 and unicode add: --enable-gtk2 \ - --enable-unicode + --enable-unicode \ Notice that I used a prefix of /opt/wx/2.5. You can use whatever - path you want, even the standard ones if you like, but this lets me - easily have multiple versions and ports of wxWindows "installed" - and makes it easy to switch between them. + path you want, such as a path in your HOME dir or even one of the + standard prefix paths such as /usr or /usr/local if you like, but + using /opt this way lets me easily have multiple versions and ports + of wxWindows "installed" and makes it easy to switch between them, + without impacting any versions of wxWindows that may have been + installed via an RPM or whatever. For the rest of the steps below + be sure to also substitute "/opt/wx/2.5" with whatever prefix you + choose for your build. + + If you want to use the image and zlib libraries included with + wxWindows instead of those already installed on your system, (for + example, to reduce dependencies on 3rd party libraries) then you + can add these flags to the configure command:: + + --with-libjpeg=builtin \ + --with-libpng=builtin \ + --with-libtiff=builtin \ + --with-zlib=builtin \ -2. To build and install wxWindows you could just use "make" but there - are other libraries that also need to be built so again I make a - script to do it all for me so I don't forget anything. This time - it is called ".make" (I use the leading ". so when I do "rm -r *" - in my build dir I don't lose my scripts too.) This is what it - looks like:: +2. To build and install wxWindows you could just use the "make" + command but there are other libraries besides the main wxWindows + libs that also need to be built so again I make a script to do it + all for me so I don't forget anything. This time it is called + ".make" (I use the leading ". so when I do "rm -r *" in my build + dir I don't lose my scripts too.) This is what it looks like:: make $* \ && make -C contrib/src/gizmos $* \ @@ -95,8 +123,13 @@ place, then do the same for wxPython. these commands, so it won't impact your already installed version of the latest release. You'll be able test with this version when you want to, and use the installed release version the rest of the - time. If you ever do want to install the development verison just - use the normal distutils commands to do it. + time. If do want to install the development verison please read + INSTALL.txt. + + If you have more than one version of Python on your system then be + sure to use the version of Python that you want to use when running + wxPython programs to run the setup.py commands below. I'll be + using python2.3. Make sure that the first wx-config found on the PATH is the one you installed above, and then change to the wxWindows/wxPython dir and @@ -105,6 +138,12 @@ place, then do the same for wxPython. cd wxPython python2.3 setup.py build_ext --inplace --debug + If your new wx-config script is not on the PATH, or there is some + other version of it found first, then you can add this to the + command line to ensure your new one is used instead:: + + WX_CONFIG=/opt/wx/2.5/bin/wx-config + If you are building with GTK2 then add the following flags to the command line:: @@ -116,6 +155,11 @@ place, then do the same for wxPython. USE_SWIG=1 SWIG=/opt/swig/bin/swig + If you get errors about wxGLCanvas or being unable to find libGLU + or something like that then you can add BUILD_GLCANVAS=0 to the + setup.py command line to disable the building of the glcanvas + module. + When the setup.py command is done you should have fully populated wxPython and wx packages locally in wxWindows/wxPython/wxPython and .../wx, with all the extension modules (*.so files) located in the @@ -130,6 +174,21 @@ place, then do the same for wxPython. cd /myprojects/wxWindows/wxPython/demo python2.3 demo.py + OS X NOTE: You need to use "pythonw" on the command line to run + wxPython applications. This version of the Python executable is + part of the Python Framework and is allowed to interact with the + display. You can also Double Click on a .py or a .pyw file from + the finder (assuming that PythonLauncher is still associated with + these file extensions) and it will launch the Framework version of + Python for you. For information about creating Applicaiton Bundles + of your wxPython apps please see the wiki and the mail lists. + + SOLARIS NOTE: If you get unresolved symbol errors when importing + wxPython and you are running on Solaris and building with gcc, then + you may be able to work around the problem by uncommenting a bit of + code in setup.py and building again. Look for 'SunOS' in setup.py + and uncomment the block containing it. The problem is that Sun's ld + does not automatically add libgcc to the link step. @@ -148,8 +207,8 @@ using VisualStudio.Net (a.k.a. MSVC 7.1) keep in mind that you'll also have to build Python and any other extension modules that you use with that compiler because a different version of the C runtime likbrary is used. The Python executable that comes from PythonLabs and the -wxPythons that I distribute are built with MSVC 6 with all the Service -Packs applied. +wxPython extensions that I distribute are built with MSVC 6 with all +the Service Packs applied. If you want to build a debugable version of wxWindows and wxPython you will need to have also built a debug version of Python and any other @@ -179,10 +238,11 @@ here. There is a copy of my build scripts in wxWindows\wxPython\distrib\msw cd %WXWIN%\include\wx\msw copy setup0.h setup.h -3. Edit setup.h and change a few settings. Some of them are changed - by my build scripts depending on the type of build (debug/hybrid, - unicode/ansi). I change a few of the other defaults to have these - values:: + +3. Edit %WXWIN%\include\wx\msw\setup.h and change a few settings. + Some of them are changed by my build scripts depending on the type + of build (debug/hybrid, unicode/ansi). I change a few of the other + defaults to have these values:: wxDIALOG_UNIT_COMPATIBILITY 0 wxUSE_DEBUG_CONTEXT 1 @@ -196,10 +256,12 @@ here. There is a copy of my build scripts in wxWindows\wxPython\distrib\msw 4. Make a %WXWIN%\BIN directory and add it to the PATH. My build scripts will copy the wxWindows DLLs there. + 5. Change to the %WXWIN%\build\msw directory and copy my build scripts there. -6. Use the .make command to build wxWindows. It needs one + +6. Use the .make.btm command to build wxWindows. It needs one command-line parameter which controls what kind of build(s) to do. Use one of the following:: @@ -214,21 +276,30 @@ here. There is a copy of my build scripts in wxWindows\wxPython\distrib\msw .make hybrid + You can also pass additional command line parameters as needed and + they will all be passed on to the nmake commands, for example to + clean up the build:: -7. When that is done there should be a ton of DLLs in %WXDIR%\bin and - lots of lib files and stuff in %WXDIR%\lib\vc_dll + .make hybrid clean + + +7. When that is done it will have built the main wxWindows DLLs and + also some of the contribs DLLs. There should be a ton of DLLs in + %WXDIR%\bin and lots of lib files and other stuff in + %WXDIR%\lib\vc_dll. 8. Building wxPython on Windows is very similar to doing it for the unix systems. We're not going to install the development version of wxPython with these commands, so it won't impact your already - installed version of the latest release. You'll be able test with - this version when you want to, and use the installed release + installed version of the latest release. You'll be able to test + with this version when you want to, and use the installed release version the rest of the time. If you ever do want to install the - development verison just use the normal distutils commands to do - it. + development verison please refer to INSTALL.txt. - Change to the wxWindows\wxPython dir and run the this command:: + Change to the wxWindows\wxPython dir and run the this command, + makeing sure that you use the version of python that you want to + build for (if you have more than one on your system):: cd %WXWIN%\wxPython python setup.py build_ext --inplace @@ -239,16 +310,21 @@ here. There is a copy of my build scripts in wxWindows\wxPython\distrib\msw USE_SWIG=1 SWIG=e:\projects\SWIG-cvs\swig.exe + If you built a Unicode version of wxWindows and want to also build + the Unicode version of wxPython then add this flag:: + + UNICODE=1 + If you have a debug version of Python and wxWindows and want to build a debug version of wxPython too, add the --debug flag to the command line. You should then end up with a set of *_d.pyd files - in the wx package and you'll have to use python_d.exe to use them. + in the wx package and you'll have to run python_d.exe to use them. The debug and hybrid(release) versions can coexist. When the setuyp.py command is done you should have fully populated wxPython and wx packages locally in wxWindows/wxPython/wxPython and - .../wx, with all the extension modules (*.pyd files) located in the - wx package. + wxWindows/wxPython/wx, with all the extension modules (*.pyd files) + located in the wx package. 9. To run code with the development verison of wxPython, just set the @@ -258,3 +334,4 @@ here. There is a copy of my build scripts in wxWindows\wxPython\distrib\msw cd e:\projects\wxWindows\wxPython python demo.py + diff --git a/wxPython/docs/BUILD.unix.txt b/wxPython/docs/BUILD.unix.txt deleted file mode 100644 index 00f7ae94a5..0000000000 --- a/wxPython/docs/BUILD.unix.txt +++ /dev/null @@ -1,340 +0,0 @@ -Building wxPython on Unix or Unix-like Systems ----------------------------------------------- - -NOTE: You should probably look at the ../ README.1st.txt file for -directions for how to build wxPython the "new way." This files -describes the "old way" to build on unix-like systems. The difference -is very simple: The new way uses a private copy of wxGTK while the -old way uses either an existing wxGTK that may be installed and used -by other apps, or you can build a wxGTK that will be accessable by -other apps. - - -NOTE 2: 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. I've made several modifications to and older version of SWIG -that are specific to wxPython's needs and so the modified sources are -included in the wx CVS at .../wxPython/wxSWIG. But because of the -size and since most people won't need it my SWIG is not included in -the wxPythonSrc tarball. You'll need to get it from CVS or a CVS -snapshot. - -If you need to modify the *.i files for wxPython then you will need to -build wxswig. Change to the .../wxPython/wxSWIG 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. - -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 -you'll need to download and install Distutils 1.0 from -http://www.python.org/sigs/distutils-sig/ - -Okay, now on the the fun stuff... - - -1. Compile and/or install glib and gtk+ ---------------------------------------- - -A. First of all, check and see if you've already got glib/gtk+ on your - system, all the Linux distributions I know of come with it, at - least as an option. Look for libglib.* and libgtk.* in your system's - standard library directories. You'll also need the headers and - config scripts in order to build things that use glib/gtk. Try - running gtk-config: - - gtk-config --version - - If you have version 1.2.7 or better then you're all set. Otherwise - either get the pacakges for your unix distribution and install them - or get the sources from www.gtk.org and build and install them. - - The best version to get is the latest 1.2.x release as the - wxWindows support for GTK 2.x is still beta-level. (Most tings - work great though, and it looks real nice.) - - - -2. Compile and/or install wxGTK -------------------------------- - -A. You can find the sources and RPMs for wxGTK at - http://wxwindows.org/, just follow the download links from the - navigation panel. - - Source code for wxGTK is now included with the wxPythonSrc tarball, - and is the recommended way to get released wxGTK source code if you - plan on building both. - - 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 - advantage of using wxPythonSrc or CVS is that you'll get both at - the same time.) - - -C. If using the RPMs be sure to get both the wxGTK and wxGTK-devel - RPMs (at a minimum) and then install them as root. - - rpm -Uhv wxGTK-2.2.2-0.i386.rpm wxGTK-devel-2.2.2-0.i386.rpm - - -D. If using the sources (either from the tarball or from CVS) then - configure it like this: - - cd wxWindows # or whatever your top-level directory is called - mkdir build - cd build - ../configure --with-gtk --enable-geometry - - There are gobs and gobs of options for the configure script, run - ../configure --help to see them all. I'll describe some that I find - useful here. - - If you have OpenGL or compatible libraries installed, then add the - --with-opengl flag. - - If you are on Solaris and are using a recent version of GCC, then - you'll probably want to add the --enable-permissive flag so the - compiler won't barf on your broken X11 header files. - - To make a debugging version of wxGTK, add the --enable-debug flag. - This sets the -g flag for the compiler and also activates some - special debugging code in wxWindows by defining the __WXDEBUG__ - macro. You'll get some extra asserts, failure logging, etc. - - If you are using GTK 2.x then you'll want to add --enable-gtk2 and - probably also --enable-unicode. - - -E. Now just compile and install. You need to use GNU make, so if your - system has something else get GNU make and build and install it and - use it instead of your system's default make command. - - make - make install - - The last step will probably have to be done as root. Also, if your - system needs anything done to update the dynamic loader for shared - libraries, (such as running ldconfig on Linux) then do it now. - - -F. You can test your build by changing to one of the directories under - build/samples or build/demos, running make and then running the - executable that is built. - - - -3. Compile and install wxPython -------------------------------- - -A. You have the same options (and same advantages/disadvantages) for - getting the wxPython source, either a released snapshot or from - CVS. The released version file is named wxPythonSrc-[version].tar.gz - and is available at http://wxpython.org/download.php. If you want - to use CVS you'll find wxPython in the wxWindows CVS tree (see - above) in the wxWindows/wxPython directory. - - -B. wxPython is built with the standard Python Distutils tool and - currently includes it's own snapshot of the latest version of - distutils which can also be used with previous versions of Python - - On Unix systems Distutils figures out what commands and flags to - use for the compiler and linker by looking in the Makefile that was - used to build Python itself. Most of the time this works okay. If - it doesn't, there doesn't seem to be a way to override the values - that Distutils uses without hacking either Distutils itself, or - Python's Makefile. (NOTE: This has been changed with the - distutilsincluded with Python 2.3 but I havn't yet looked into how - best to utilize this in wxPython...) - - While we're on the subject of how Python was built... Since - wxPython is a C++ extension some platforms and/or compilers will - require that the Python executable was linked with the C++ linker - in order for everything to work correctly. If you build and - install Python yourself then this is easy to take care of, - otherwise you may have to mess with binary packages or bribe your - system administrator... - - In my case on Solaris wxPython applications would core dump on - exit. The core file indicated that the fault happened after - _exit() was called and the run-time library was trying to execute - cleanup code. After relinking the Python executable the problem - went away. To build Python to link with the C++ linker do this: - - cd Python-2.0 # wherever the root of the source tree is - rm python # in case it's still there from an old build - make LINKCC=g++ # or whatever your C++ command is - make install - - I recently built Python 2.1.3 and Python 2.2.1 on Solaris and did - not have to resort to this workaround so apparently things are - getting better there. I will leave this note here though in case - there are similar issues elsewhere. However I did run into a - Python build issue that affects the wxPython build when attempting - to use SunCC instead of GNU gcc. See the note below titled - "Building with non-GNU compilers" if you are interested. - - -C. Change to the root wxPython directory and look at the setup.py - file. This is the script that configures and defines all the - information that Distutils needs to build wxPython. There are some - options near the begining of the script that you may want or need - to change based on your system and what options you have selected - up to this point, (sources from tar.gz or from CVS, etc.) You can - either change these flags directly in setup.py or supply them on - the command-line. - - BUILD_GLCANVAS Set to zero if you don't want to build the - Open GL canvas extension module. If you don't - have OpenGL or compatible libraries then you'll - need to set this to zero. - - BUILD_OGL Set to zero if you don't want to build the - Object Graphics Library extension module. - - BUILD_STC Set to zero if you don't want to build the - wxStyledTextCtrl (the Scintilla wrapper) - extension module. - - USE_SWIG If you have edited any of the *.i files you - will need to set this flag to non-zero so SWIG - will be executed to regenerate the wrapper C++ - and shadow python files. - - etc. - - -D. To build and install wxPython you simply need to execute the - setup.py script. If you have more than one version of Python - installed, be sure to execute setup.py with the version you want to - build wxPython for. Depending on the permissions on your - site-packages directory you may need to be root to run the install - command. - - python setup.py build install - - If you need to change any of the build flags that can also be done - on the setup.py command line, like this: - - python setup.py BUILD_GLCANVAS=0 build install - - If you are using GTK 2.x then you'll want to add these flags: - - python setup.py WXPORT=gtk2 UNICODE=1 build install - - If you would like to install to someplace besides the Python - site-packages directory (such as to your home directory) then you - can add "--root=" after the "install" command. To use - wxPython like this you'll need to ensure that the directory - containing wxPyrthon is contained in in the PYTHONPATH environment - variable. - - -E. At this point you should be able to change into the wxPython/demo - directory and run the demo: - - python demo.py - - -F. If you would like to make a test build that doesn't overwrite any - installed version of wxPython you can do so with this command - instead of the install command above: - - python setup.py build_ext --inplace - - This will build the wxPython package in the local wxPython - directory instead of installing it under your Python installation. - To run using this test version just add the base wxPython source - directory to the PYTHONPATH: - - export PYTHONPATH=~/projects/wxWindows/wxPython - # or whatever is required for your shell - cd ~/projects/wxWindows/wxPython/demo - python demo.py - - - -4. Building with non-GNU compilers ----------------------------------- - -As mentioned above Python's distutils uses whatever compiler Python -was compiled with to compile extension modules. It also appears that -distutils assumes that this compiler can compile C or C++ sources as -distutils makes no differentiation between the two. For builds using -GNU gcc and a few other compilers this is not an issue as they will -determine the type of source from the file extension. For SunCC (and -probably other compilers that came from cfront) it won't work as the C -compiler (cc) is totally separate from the C++ compiler (CC). This -causes distutils to attempt to compile the wxPython sources with the C -compiler, which won't work. - -There may be better ways to get around this, but here is the -workaround I devised. I created a script that will execute either cc -or CC based on the file extension given to it. If Python uses this -script for its compiler then it will also be used by extensions built -with distutils and everybody will be more or less happy. Here is a -copy of the script I used. It was a fairly quick rush job so there -are probably issues with it but it worked for me. - - #!/bin/bash - #-------------------------------------------------------------- - # Try to determine type of file being compiled and then - # launch cc for C sources or CC for C++. - # - - args=$@ - is_C= - - for arg in $args; do - - # is the arg a file that exists? - if [ -e $arg ]; then - - # does it end in ".c"? - if [ "${arg:${#arg}-2}" == ".c" ]; then - is_C=yes - fi - fi - done - - # if the flag wasn't set then assume C++ and execute CC, - # otherwise execute cc. - if [ -z $is_C ]; then - exec CC -w $@ - else - exec cc -w $@ - fi - #-------------------------------------------------------------- - -I called it pycc, put it in ${prefix}/bin and set its execute -permission bit. - -The next step is to configure and build Python such that it uses pycc -as it's compiler. You can do that by setting CC in your environment -before running configure, like this in bash: - - export CC=pycc - configure - -After making and installing Python with this configuration you should -be able to build wxPython as described in the steps above. - - - ------------------ -robin@alldunn.com diff --git a/wxPython/docs/BUILD.win32.txt b/wxPython/docs/BUILD.win32.txt deleted file mode 100644 index 3c55ece697..0000000000 --- a/wxPython/docs/BUILD.win32.txt +++ /dev/null @@ -1,303 +0,0 @@ -Building wxPython on Win32 --------------------------- - - -Building wxPython for use on win32 systems is a fairly simple process -consisting of just a few steps. However depending on where you get -your sources from and what your desired end result is, there are -several permutations of those steps. At a high level the basic steps -are: - - 1. Get the sources - 2. Build the wxWindows DLL - 3. Build and Install wxPython - -We'll go into more detail of each of these steps below, but first a -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. 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. -But because of the size and since most people won't need it my SWIG is -not included in the wxPythonSrc tarball. You'll need to get it from -CVS or a CVS snapshot. - -If you need to modify the *.i files for wxPython then change to the -.../wxPython/wxSWIG 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 -you'll need to download and install Distutils 1.0 from -http://www.python.org/sigs/distutils-sig/ - -I use Microsoft Visual C++ 6.0 (5.0 with the service packs should work -also) to compile the wxPython C++ sources. Since I am using Distutils -it should be easier now to build with other win32 compilers such as -the free mingw32 or Borland compilers, but I havn't tried them yet. -If anybody wants to try it I'll take any required patches for the -setup script and for these instructions. - - - -UNICODE -------- - -To build the version of wxWindows/wxPython that uses the unicode -version of the Win32 APIs, just follow the steps below with these -changes: - - a. You'll need the MSLU runtime DLL and import lib. The former can - be downloaded from Microsoft, the latter is part of the latest - Platform SDK from Microsoft (see msdn.microsoft.com for - details). An alternative implementation of import lib can be - downloaded from http://libunicows.sourceforge.net - - b. Add "UNICODE=1 MSLU=1" to the nmake command line when building - wxWindows. - - c. Add "UNICODE=1" to the setup.py commandline when building - wxPython. - - d. See the notes in CHANGES.txt about unicode. - - -And now on to the fun stuff... - - - - -1. Get the sources ------------------- - -A. You can either use a tarball with the released version of the - source code for wxWindows/wxPython, or you can get current - development sources from the CVS repository. (Some 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 thorough testing done. You can decide which method is best - for you. The released version file is named - wxPythonSrc-[version].tar.gz and is available from the wxPython - website at http://wxpython.org/download.php. You can use WinZip to - unpack it if you don't have tar and gzip. - - -B. Once you get the sources be sure to put them in a path without a - space in it (i.e., NOT c:\Program Files\wx) and set an environment - variable named WXWIN to the top level directory. For example: - - set WXWIN=c:\wx\wxPythonSrc-2.4.0.4 - - You'll probably want to add that line to your autoexec.bat or - System Properties depending on the type of system you are on. - - -C. Change to the %WXWIN%\include\wx\msw directory and copy setup0.h to - setup.h and then edit setup.h. This is how you control which parts - of wxWindows are compiled into or left out of the build, simply by - turning options on or off. I have the following differences from - 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_DEBUG_CONTEXT 1 - wxUSE_MEMORY_TRACING 1 - wxUSE_CMDLINE_PARSER 0 - wxUSE_FSVOLUME 0 - wxUSE_DIALUP_MANAGER 0 - wxUSE_DYNAMIC_LOADER 0 - wxUSE_TREELAYOUT 0 - wxUSE_MS_HTML_HELP 0 - wxUSE_POSTSCRIPT 1 - - - ** NEW ** - Be sure that wxUSE_GLCANVAS is defined to be 0 as wxPython now - keeps its own copy of the glcanvas sources and expects that it is - not in the main library. This is done to reduce the number of - dependant DLLs on the core library and therefore help reduce - startup time. - - - -2. Build the wxWindows DLL ---------------------------- - -A. Although MSVC project files are provided I always use the makefiles - to build wxWindows because by default the flags are compatible with - Python, (and I make sure they stay that way.) You would have to - edit the project files a bit to make it work otherwise. - - -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. - Here are some more details: - - DEBUG Specified with "FINAL=0" and produces a DLL named - 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 - pythonXX_d.dll) which also means that all extensions - loaded by Python should also have the _d in the name. - With this option you can use the MSVC debugger to trace - though the Python interpreter, as well as the code for the - wxPython extension and the wxWindows DLL. - - FINAL Specified with "FINAL=1" and produces a DLL named - 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. - - HYBRID Specified with "FINAL=hybrid" and produces a DLL named - wxmsw[version]h.dll. This DLL is almost the same as the - FINAL version except the __WXDEBUG__ is used which means - that you will get extra runtime assertions and validations - from wxWindows. If any of these fail then they are turned - into a Python exception that you can catch and deal with - in your code. This is the version that I use when making - the binary installer for win32. - - - Since different DLL names and object file directories are used you - can build all three types if you like. - - -C. Change to the %WXWIN%\src\msw directory and type the following command, - using the value for FINAL that you want: - - nmake -f makefile.vc dll FINAL=hybrid - - Your machine will then crunch away for possibly a long time, - depending on your hardware, and when it's done you should have a - DLL and some library files in %WXWIN%\lib. - - -D. You'll either need to add %WXWIN%\lib to the PATH or copy the DLL - file 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 - %WXWIN%\samples or %WXWIN\demos and typing (using the right FINAL flag): - - nmake -f makefile.vc FINAL=hybrid WXUSINGDLL=1 - - and then executing the resulting .exe file. - - - - -3. Build and Install wxPython ------------------------------ - -A. As mentioned previouslly, wxPython is built with the standard - 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/. - - -B. Change to the root wxPython directory and look at the setup.py - file. This is the script that configures and defines all the - information that Distutils needs to build wxPython. There are some - options near the begining of the script that you may want or need - to change based on what options you have selected up to this point, - (type of DLL built, sources from tar.gz or from CVS, etc.) You can - either change these flags directly in setup.py or supply them on - the command-line. - - BUILD_GLCANVAS Set to zero if you don't want to build the - Open GL canvas extension module. - - BUILD_OGL Set to zero if you don't want to build the - Object Graphics Library extension module. - - BUILD_STC Set to zero if you don't want to build the - wxStyledTextCtrl (the Scintilla wrapper) - extension module. - - USE_SWIG If you have edited any of the *.i files you - will need to set this flag to non-zero so SWIG - will be executed to regenerate the wrapper C++ - and shadow python files. - - etc. - - -C. To build and install wxPython you simply need to execute the - setup.py script. If you have more than one version of Python - installed, be sure to execute setup.py with the version you want to - build wxPython for. - - Depending on what kind of wxWindows DLL you built there are - different command-line parameters you'll want to pass to setup (in - addition to possibly one or more of the above): - - FINAL: python setup.py install - - DEBUG: python setup.py build --debug install - - HYBRID: python setup.py HYBRID=1 install - - NOTE: If you get an internal compiler error from MSVC then you - need to edit setup.py and add in the /GX- flag that is normally - commented out. Just search for "GX-" and uncomment it so it is put - into the cflags list. - - If you would like to install to someplace besides the Python - site-packages directory (such as to your home directory) then you - can add "--root=" after the "install" command. To use - wxPython like this you'll need to ensure that the directory - containing wxPyrthon is contained in in the PYTHONPATH environment - variable. - - -D. At this point you should be able to change into the wxPython\demo - directory and run the demo: - - python demo.py - - -E. If you would like to make a test build that doesn't overwrite the - installed version of wxPython you can do so with one of these - commands instead of the install command above: - - FINAL: python setup.py build_ext --inplace - - DEBUG: python setup.py build_ext --debug --inplace - - HYBRID: python setup.py HYBRID=1 build_ext --inplace - - This will build the wxPython package in the local wxPython - directory instead of installing it under your Python installation. - To run using this test version just add the base wxPython source - directory to the PYTHONPATH: - - set PYTHONPATH=%WXDIR%\wxPython - cd %WXDIR%\wxPython\demo - python demo.py - - -That's all folks! - - ------------------ -robin@alldunn.com - diff --git a/wxPython/docs/INSTALL.txt b/wxPython/docs/INSTALL.txt new file mode 100644 index 0000000000..cb21cd4991 --- /dev/null +++ b/wxPython/docs/INSTALL.txt @@ -0,0 +1,133 @@ +Installing wxPython 2.5 from Source +=================================== + + +This document will describe the few differences and additions to the +content in BUILD.txt for installing wxPython built from source. +Please follow the intstructions both in this file and in BUILD.txt to +perform this task. Where there is overlap the items described here +will take precedence. + + + + +Installing on Unix-like Systems (not OS X) +------------------------------------------ + +1. When building wxWindows you need to decide if you want it to be a + private copy only accessed by wxPython, or if you would like it to + be installed in a stanard location such as /usr. Or perhaps you + already have a version of wxWindows installed on your system (such + as from an RPM) and you want wxPython to use that version too. If + so then you'll want to ensure that the flags and options used to + build the installed version are compatible with wxPython. + + +2. If you do decide to build and install your own wxWindows then there + are a few tweaks to the configure flags described in BUILD.txt that + you will probably want to make. Instead of --enable-debug use + this configure flag:: + + --enable-optimize \ + + Normally I also use the following flag in order to have wxWindows + runtime assertions turned into Python exceptions where possible. + It does add extra code to the build but probably not enough to + worry about it. However if you want to get as lean a build as + possible you can leave it out, but if your code does something bad + then instead of exceptions you'll likely get a crash. + + --enable-debug_flag \ + + If you are building a private copy of wxWindows (IOW, not installed + in a standard library location) the it can be kind of a hassle to + always have to set the LD_LIBRARY_PATH variable so wxPython can + find the wxWindows shared libraries. You can hard code the library + path into the binaries by using the rpath option when configuring + wxWindows. For example:: + + --enable-rpath=/opt/wx/2.5/lib \ + + SOLARIS NOTE: The --enable-rpath option may cause problems when + using wxGTK on Solaris when compiling wxPython as described below. + The woraround is to not use --enable-rpath flag for configure, but + in that case all wxPython applications must have the + LD_LIBRARY_PATH set to include $WXPREF/lib, or you can use the + 'crle' program to modify the runtime linking environment. If this + is the only installation of wxGTK on the system then you can use a + system library path for prefix and not have to worry about it at + all. + + +3. Build and install wxGTK as described in BUILD.txt. + + +4. In addition to building wxPython as described in BUILD.txt, you can + install it to Python's site-packages dir, as well as some scrpts + into the same bin dir used by Python by using this command:: + + python2.3 setup.py install + + If you would like to install to some place besides the prefix where + Python is installed, (such as to your home directory) then you can + add "--root=" after the "install" command. This will use + as the prefix and will install scripts to a bin subdir and + the wxPython packages to a lib subdir. To use wxPython like this + you'll need to ensure that the directory containing wxPython is + contained in the PYTHONPATH environment variable. + + + + +Installing on OS X +------------------ + +Installing wxPython on OS X is nearly the same as the Unix +instructions above, except for a few small, but important details: + +1. The --enable-rpath configure option is not supported. (At least it + didn't the last time I checked...) If there is a way to do + something similar please let me know. + +2. If you don't install wxWindows to a standard location you will need + to use the DYLD_LIBRARY_PATH environment variable instead of the + LD_LIBRARY_PATH described above. + +3. Depending on the version of OS X Python may be installed in + differnet locations. On 10.2 (Jaguar) you need to download and + install MacPython-OSX-2.3 from http://www.python.org/ and the + Python Framework will then be installed in /Library/Frameworks. On + 10.3 (Panther) Apple supplies the Python Framework as part of the + OS install, but it will located in /System/LIbrary/Frameworks + instead. To complicate things further, the Jaguar version, or a + custom build you do yourself will end up in /Library/Frameworks + even on Panther... + +4. You need to use pythonw atg the command line or PythonLauncher app + to run wxPython apps. + + + + + +Installing on Windows +--------------------- + +1. Build wxWindows and wxPython as described in BUILD.txt. If you + would rather have a version without the code that turns runtime + assertions into Python exceptions, then use "release" instead of + "hybrid" when building wxWindows and add "FINAL=1" to the setup.py + command line. + +2. Install wxPython like this:: + + python setup.py install + + +3. Copy the wxWindows DLLs to the wx package directory so they can be + found at runtime by the extension modules without requiring that + they be installed on the PATH:: + + copy %WXWIN%\BIN\wx*h_*.dll c:\Python23\Lib\site-pacakges\wx + +