From: Robin Dunn Date: Thu, 8 Jan 2004 00:30:39 +0000 (+0000) Subject: Updated build and install docs X-Git-Url: https://git.saurik.com/wxWidgets.git/commitdiff_plain/7d3000f8db5c13ea25ea2bc86ac80ba1c3b6f7a0 Updated build and install docs git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@25086 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775 --- 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: - - export WXPREF=/usr/lib/wxPython +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:: + cvs update -r wxPy_2_5_1_0 -2. Make a build directory and configure wxGTK. - - 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. +For more details about building and installing wxWindows and wxPython +please see these files:: - 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. + wxPython/docs/BUILD.txt + wxPython/docs/INSTALL.txt - 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 \ +For a log of recent changes check these files:: - 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: + docs/changes.txt (for wxWindows) + wxPython/docs/CHANGES.txt (for wxPython) - --enable-gtk2 \ - --enable-unicode \ +And for information about major changes in wxPython 2.5 and how to +migrate your existing code to 2.5 please read this file:: -3. Build and install wxGTK. (You may need to be root for the last - step, depending on where your WXPREF is.) + wxPython/docs/MigrationGuide.txt - make - make install +Further information can be found on the wxWindows and wxPython web +sites and wikis:: -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.) + http://www.wxwindows.org/ + http://wiki.wxwindows.org/ - cd ../wxPython - python setup.py \ - WX_CONFIG=$WXPREF/bin/wx-config \ - build install + http://www.wxpython.org/ + http://wiki.wxpython.org/ - 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 +And be sure to direct your questions to one of the various mail +lists:: - 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. + http://www.wxpython.org/maillist.php - 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. -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 - - -6. Change to the demo directory and run it like this: - - python demo.py - - 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.devel.txt b/wxPython/docs/BUILD.devel.txt deleted file mode 100644 index 262ea0bbee..0000000000 --- a/wxPython/docs/BUILD.devel.txt +++ /dev/null @@ -1,260 +0,0 @@ -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. - -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 -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. - - - - -Building on Linux and OS X --------------------------- - -These two 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. - - -1. Create a build directory in the main wxWindows dir, and configure - wxWindows. If you want to have multiple builds with different - configure options, just use different subdirectories. I normally - put the configure command in a script named ".configure" in each - build dir so I can easily blow away everything in the build dir and - rerun the script without having to remember the options I used - before:: - - mkdir bld - cd bld - ../configure --prefix=/opt/wx/2.5 \ - --with-gtk \ - --with-opengl \ - --disable-monolithic \ - --enable-debug \ - --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 - - 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. - - -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:: - - make $* \ - && make -C contrib/src/gizmos $* \ - && make -C contrib/src/ogl CXXFLAGS="-DwxUSE_DEPRECATED=0" $* \ - && make -C contrib/src/stc $* \ - && make -C contrib/src/xrc $* - - So you just use .make as if it where make, but don't forget to set - the execute bit on .make first!:: - - .make - .make install - - When it's done you should have an installed set of files under - /opt/wx/2.5 containing just wxWindows. Now to use this version of - wxWindows you just need to add /opt/wx/2.5/bin to the PATH and set - LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on OS X) to /opt/wx/2.5/lib. - - -3. I also have a script to help me build wxPython and it is checked in - to the CVS as wxWindows/wxPython/b, but probably don't want to use - it as it's very cryptic and expects that you want to run SWIG, so - if you don't have the latest patched up version of SWIG then you'll - probably get stuck. So I'll just give the raw commands instead. - - 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 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. - - 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 - run the this command:: - - cd wxPython - python2.3 setup.py build_ext --inplace --debug - - If you are building with GTK2 then add the following flags to the - command line:: - - WXPORT=gtk2 UNICODE=1 - - If you are wanting to have the source files regenerated with swig, - then you need to turn on the USE_SWIG flag and optionally tell it - where to find the new swig executable, so add these flags:: - - USE_SWIG=1 SWIG=/opt/swig/bin/swig - - 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 - wx package. - - -4. To run code with the development verison of wxPython, just set the - PYTHONPATH to the wxPython dir in the CVS tree. For example:: - - export LD_LIBRARY=/opt/wx/2.5/lib - export PYTHONPATH=/myprojects/wxWindows/wxPython - cd /myprojects/wxWindows/wxPython/demo - python2.3 demo.py - - - - - -Building on Windows -------------------- - -The Windows builds currently require the use of Microsoft Visual C++. -Theoretically, other compilers (such as mingw32 or the Borland -compilers) can also be used but I've never done the work to make that -happen. If you want to try that then first you'll want to find out if -there are any tricks that have to be done to make Python extension -modules using that compiler, and then make a few changes to setup.py -to accomodate that. (And send the patches to me.) If you plan on -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. - -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 -extension modules you need to use. You can tell if you have them -already if there is a _d in the file names, for example python_d.exe -or python23_d.dll. If you don't need to trace through the C/C++ parts -of the code with the debugger then building the normal (or hybrid) -version is fine, and you can use the regular python executables with -it. - -Just like the unix versions I also use some scripts to help me build -wxWindows, but I use some non-standard stuff to do it. So if you want -to use them too you'll need to get a copy or 4DOS or 4NT from -http://www.jpsoft.com/ and also a copy of unix-like cat and sed -programs. You can also do by hand what my scripts are doing, but -there are a lof steps involved and I won't be going into details -here. There is a copy of my build scripts in wxWindows\wxPython\distrib\msw - - -1. Set an environment variable to the root of the wxWindows source - tree:: - - set WXWIN=e:\projects\wxWindows - -2. Copy setup0.h to setup.h - - 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:: - - wxDIALOG_UNIT_COMPATIBILITY 0 - wxUSE_DEBUG_CONTEXT 1 - wxUSE_MEMORY_TRACING 1 - wxUSE_DIALUP_MANAGER 0 - wxUSE_GLCANVAS 1 - wxUSE_POSTSCRIPT 1 - wxUSE_AFM_FOR_POSTSCRIPT 0 - - -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 - command-line parameter which controls what kind of build(s) to do. - Use one of the following:: - - debug Build debug version - hybrid Build hybrid version - both Both debug and hybrid - debug-uni Build a debug unicode library - hybrid-uni Hybrid unicode (see the pattern yet? ;-) - both-uni and finally both unicode libraries - - For example:: - - .make hybrid - - -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 - - -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 - 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. - - Change to the wxWindows\wxPython dir and run the this command:: - - cd %WXWIN%\wxPython - python setup.py build_ext --inplace - - If you are wanting to have the source files regenerated with swig, - then you need to turn on the USE_SWIG flag and optionally tell it - where to find the new swig executable, so add these flags:: - - USE_SWIG=1 SWIG=e:\projects\SWIG-cvs\swig.exe - - 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. - 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. - - -9. To run code with the development verison of wxPython, just set the - PYTHONPATH to the wxPython dir in the CVS tree. For example:: - - set PYTHONPATH=e:\projects\wxWindows\wxPython - cd e:\projects\wxWindows\wxPython - python demo.py - 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.txt b/wxPython/docs/BUILD.txt new file mode 100644 index 0000000000..fb78c5c483 --- /dev/null +++ b/wxPython/docs/BUILD.txt @@ -0,0 +1,337 @@ +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 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 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. + + + + +Building on Unix-like Systems (e.g. Linux and OS X) +--------------------------------------------------- + +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. + + +1. Create a build directory in the main wxWindows dir, and configure + wxWindows. If you want to have multiple builds with different + configure options, just use different subdirectories. I normally + put the configure command in a script named ".configure" in each + build dir so I can easily blow away everything in the build dir and + rerun the script without having to remember the options I used + before:: + + mkdir bld + cd bld + ../configure --prefix=/opt/wx/2.5 \ + --with-gtk \ + --with-opengl \ + --disable-monolithic \ + --enable-debug \ + --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 \ + + Notice that I used a prefix of /opt/wx/2.5. You can use whatever + 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 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 $* \ + && make -C contrib/src/ogl CXXFLAGS="-DwxUSE_DEPRECATED=0" $* \ + && make -C contrib/src/stc $* \ + && make -C contrib/src/xrc $* + + So you just use .make as if it where make, but don't forget to set + the execute bit on .make first!:: + + .make + .make install + + When it's done you should have an installed set of files under + /opt/wx/2.5 containing just wxWindows. Now to use this version of + wxWindows you just need to add /opt/wx/2.5/bin to the PATH and set + LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on OS X) to /opt/wx/2.5/lib. + + +3. I also have a script to help me build wxPython and it is checked in + to the CVS as wxWindows/wxPython/b, but probably don't want to use + it as it's very cryptic and expects that you want to run SWIG, so + if you don't have the latest patched up version of SWIG then you'll + probably get stuck. So I'll just give the raw commands instead. + + 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 version the rest of the + 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 + run the this command:: + + 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:: + + WXPORT=gtk2 UNICODE=1 + + If you are wanting to have the source files regenerated with swig, + then you need to turn on the USE_SWIG flag and optionally tell it + where to find the new swig executable, so add these flags:: + + 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 + wx package. + + +4. To run code with the development verison of wxPython, just set the + PYTHONPATH to the wxPython dir in the CVS tree. For example:: + + export LD_LIBRARY=/opt/wx/2.5/lib + export PYTHONPATH=/myprojects/wxWindows/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. + + + + +Building on Windows +------------------- + +The Windows builds currently require the use of Microsoft Visual C++. +Theoretically, other compilers (such as mingw32 or the Borland +compilers) can also be used but I've never done the work to make that +happen. If you want to try that then first you'll want to find out if +there are any tricks that have to be done to make Python extension +modules using that compiler, and then make a few changes to setup.py +to accomodate that. (And send the patches to me.) If you plan on +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 +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 +extension modules you need to use. You can tell if you have them +already if there is a _d in the file names, for example python_d.exe +or python23_d.dll. If you don't need to trace through the C/C++ parts +of the code with the debugger then building the normal (or hybrid) +version is fine, and you can use the regular python executables with +it. + +Just like the unix versions I also use some scripts to help me build +wxWindows, but I use some non-standard stuff to do it. So if you want +to use them too you'll need to get a copy or 4DOS or 4NT from +http://www.jpsoft.com/ and also a copy of unix-like cat and sed +programs. You can also do by hand what my scripts are doing, but +there are a lof steps involved and I won't be going into details +here. There is a copy of my build scripts in wxWindows\wxPython\distrib\msw + + +1. Set an environment variable to the root of the wxWindows source + tree:: + + set WXWIN=e:\projects\wxWindows + +2. Copy setup0.h to setup.h + + cd %WXWIN%\include\wx\msw + copy setup0.h setup.h + + +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 + wxUSE_MEMORY_TRACING 1 + wxUSE_DIALUP_MANAGER 0 + wxUSE_GLCANVAS 1 + wxUSE_POSTSCRIPT 1 + wxUSE_AFM_FOR_POSTSCRIPT 0 + + +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.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:: + + debug Build debug version + hybrid Build hybrid version + both Both debug and hybrid + debug-uni Build a debug unicode library + hybrid-uni Hybrid unicode (see the pattern yet? ;-) + both-uni and finally both unicode libraries + + For example:: + + .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:: + + .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 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 please refer to INSTALL.txt. + + 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 + + If you are wanting to have the source files regenerated with swig, + then you need to turn on the USE_SWIG flag and optionally tell it + where to find the new swig executable, so add these flags:: + + 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 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 + 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 + PYTHONPATH to the wxPython dir in the CVS tree. For example:: + + set PYTHONPATH=e:\projects\wxWindows\wxPython + 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 + +