-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=<path>" 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!
--
+++ /dev/null
-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
-
+++ /dev/null
-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=<path>" 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. <wink>
-
---Robin
-
-
-
-
-
-
--- /dev/null
+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
+
+
+++ /dev/null
-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=<path>" 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
+++ /dev/null
-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=<path>" 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
-
--- /dev/null
+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=<path>" after the "install" command. This will use
+ <path> 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
+
+
projects / wxWidgets.git / commitdiff
