AuroraMiddleware/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Updated build and install docs

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@25086 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Robin Dunn 2004-01-08 00:30:39 +00:00
parent ec3ade90e2
commit 7d3000f8db
6 changed files with 286 additions and 882 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

151
wxPython/distrib/README.1st.txt
View File

@ -1,140 +1,57 @@
README for wxPythonSrc-*.tar.gz
-------------------------------
Prior to version 2.3.3 of wxPython I had always made my Linux/Unix
binaries based on the released binary of wxGTK and wxGTK-gl. This
imposed a few restrictions and so starting with 2.3.3 I have decided
to do a combined binary that inlcudes wxGTK as well as wxPython. This
allows me a bit more flexibility and is consistent with how the
Windows and Mac OS X binaries are built.
If you are reading this file then you are probably interested in
building your own copy of wxPython from the sources contained in this
archive. If you wish to use the released wxGTK binary as has been
done in the past then you can still follow the old build directions in
wxPython/BUILD.unix.txt. If you are building for Windows or Mac OS X
then you should look at wxPython/BUILD.win32.txt or
wxPython/BUILD.osx.txt respectivly.
If, on the other hand, you would like to build Linux/Unix binaries
with a private copy of wxGTK like what I am now distributing then
you'll want to follow the instructions in this file. (You should
probably still read wxPython/BUILD.unix.txt though since there are
other details there that you may need to be aware of.
Clear as mud? Good. Let's get started.
README for wxPythonSrc-2.5.*.tar.gz
===================================
1. We'll be making a private copy of wxGTK so it doesn't conflict with
one used by wxGTK C++ apps that expect to have the default binary
installed from RPM or whatever. I put it in /usr/lib/wxPython, but
you can use whatever you like. I'll just set a variable to our wx
prefix to reference later:
This archive contains the source code and other files for both
wxWindows and wxPython. Some things not needed for the build (such as
the wxWindows samples and docs) have been removed in order to minimize
the size of the archive. If you would like to have the complete set
of sources and etc. then please either use a CVS snapshot from
http://wxwindows.org/snapshots/ or do a checkout from CVS yourself
(see http://www.wxwindows.org/cvs.htm.) If you would like to use CVS
to get the exact same sources as one of these tarballs then you can
update using a release tag. For example::
export WXPREF=/usr/lib/wxPython
cvs update -r wxPy_2_5_1_0
2. Make a build directory and configure wxGTK.
For more details about building and installing wxWindows and wxPython
please see these files::
cd wxPythonSrc-2.4.0 # or whatever the top-level dir is
mkdir build
cd build
../configure --with-gtk \
--prefix=$WXPREF \
--enable-rpath=$WXPREF/lib \
--with-opengl \
--enable-geometry \
--enable-optimise \
--enable-debug_flag \
You may want to use --enable-debug instead of --enable-optimise if
you need to run though a debugger and want full debugging symbols.
SOLARIS NOTE: The --enable-rpath option may cause problems when
using wxGTK on Solaris when compiling wxPython in step 4 below.
The woraround is to not use --enable-rpath flag for configure, but
in that case all wxPython applications must have the
LD_LIBRARY_PATH set to include $WXPREF/lib, or you can use the
'crle' program to modify the runtime linking environment. If this
is the only installation of wxGTK on the system then you can use a
system library path for WXPREF and not have to worry about it at
all.
If you want to use the image and zlib libraries included with
wxWindows instead of those already installed on your system, (for
example, to reduce dependencies on 3rd party libraries) then you
can add these flags to the configure command:
--with-libjpeg=builtin \
--with-libpng=builtin \
--with-libtiff=builtin \
--with-zlib=builtin \
If you would like to use GTK 2.x and unicode, then add the
following flags. Please note that this is still considered beta,
but does look and work quite nice for the most part:
--enable-gtk2 \
--enable-unicode \
wxPython/docs/BUILD.txt
wxPython/docs/INSTALL.txt
3. Build and install wxGTK. (You may need to be root for the last
step, depending on where your WXPREF is.)
For a log of recent changes check these files::
make
make install
docs/changes.txt (for wxWindows)
wxPython/docs/CHANGES.txt (for wxPython)
4. Build and install wxPython. If you want to use a different version
of Python than is found by default on the PATH then specify the
whole pathname in these steps. The version of Python that runs
setup.py is the version wxPython will be built and installed for.
(You will need to be root for the install step unless your Python
is not in a system location.)
And for information about major changes in wxPython 2.5 and how to
migrate your existing code to 2.5 please read this file::
cd ../wxPython
python setup.py \
WX_CONFIG=$WXPREF/bin/wx-config \
build install
If you are using GTK 2.x and unicode then do it this way instead:
python setup.py \
WX_CONFIG=$WXPREF/bin/wx-config \
WXPORT=gtk2 UNICODE=1 \
build install
If you get errors about wxGLCanvas or being unable to find libGLU
or something like that then you can add BUILD_GLCANVAS=0 to the
setup.py command line to disable the building of the glcanvas
module.
If you would like to install to some place besides the Python
site-packages directory (such as to your home directory) then you
can add "--root=<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.
wxPython/docs/MigrationGuide.txt
5. If you havn't already, get a new copy of the demo and documentation
to go with the wxPython you just built and installed. See
http://wxpython.org/download.php#documentation
Further information can be found on the wxWindows and wxPython web
sites and wikis::
http://www.wxwindows.org/
http://wiki.wxwindows.org/
http://www.wxpython.org/
http://wiki.wxpython.org/
6. Change to the demo directory and run it like this:
And be sure to direct your questions to one of the various mail
lists::
python demo.py
http://www.wxpython.org/maillist.php
SOLARIS NOTE: If you get unresolved symbol errors when importing
wxPython and you are running on Solaris and building with gcc, then
you may be able to work around the problem by uncommenting a bit of
code in setup.py and building again. Look for 'SunOS' in setup.py
and uncomment the block containing it. The problem is that Sun's ld
does not automatically add libgcc to the link step.
7. That's all, except for the having fun part!
Have fun!
--

80
wxPython/docs/BUILD.osx.txt
View File

@ -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=<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

161
wxPython/docs/BUILD.devel.txt → wxPython/docs/BUILD.txt
View File

@ -4,16 +4,29 @@ Building wxPython 2.5 for Development and Testing
This file describes how I build wxWindows and wxPython while doing
development and testing, and is meant to help other people that want
to do the same thing. I'll assume that you are using either a CVS
snapshot or a checkout from CVS. I'll also assume that you know what
you are doing and so I may not be as detailed here as I am in other
BUILD docs.
snapshot from http://wxwindows.org/snapshots/, a checkout from CVS, or
one of the released wxPythonSrc-2.5.* tarballs. I'll also assume that
you know your way around your system, the compiler, etc. and that you
know what you are doing! ;-)
If you want to make changes to any of the *.i files, or regenerate the
extension sources or renamer modules, then you will need an up to date
version of SWIG. Either get and build the current CVS version, or
version 1.3.20 when it is released. If you install this build of SWIG
to a location that is not on the PATH (so it doesn't interfere with an
existing SWIG install for example) then you can set a setup.py
If you want to also install the version of wxPython you build to be in
your site-packages dir and be your default version of wxPython, then a
few additional steps are needed, and you may want to use slightly
different options. See INSTALL.txt for more details. If you only use
the instructions in this BUILD.txt file then you will end up with a
separate installation of wxPython and you can switch back and forth
between this and the release version that you may already have
installed.
If you want to make changes to any of the *.i files, (SWIG interface
definition files,) or to regenerate the extension sources or renamer
modules, then you will need an up to date version of SWIG. Either get
and build the current CVS version, or version 1.3.20, and then apply
the patches in wxPython/SWIG. See the README.txt in that dir for
details about each patch and also info about those that may already
have been applied to the SWIG sources. If you install this build of
SWIG to a location that is not on the PATH (so it doesn't interfere
with an existing SWIG install for example) then you can set a setup.py
command-line variable named SWIG to be the full path name of the
executable and the wxPython build will use it. See below for an
example.
@ -21,10 +34,10 @@ example.
Building on Linux and OS X
--------------------------
Building on Unix-like Systems (e.g. Linux and OS X)
---------------------------------------------------
These two platforms are built almost the same way while in development
These platforms are built almost the same way while in development
so I'll combine the descriptions about their build process here.
First we will build wxWindows and install it to an out of the way
place, then do the same for wxPython.
@ -45,27 +58,42 @@ place, then do the same for wxPython.
--with-opengl \
--disable-monolithic \
--enable-debug \
--enable-geometry
--enable-geometry \
On OS X of course you'll want to use --with-mac instead of
--with-gtk. For GTK2 and unicode add:
--enable-gtk2 \
--enable-unicode
--enable-unicode \
Notice that I used a prefix of /opt/wx/2.5. You can use whatever
path you want, even the standard ones if you like, but this lets me
easily have multiple versions and ports of wxWindows "installed"
and makes it easy to switch between them.
path you want, such as a path in your HOME dir or even one of the
standard prefix paths such as /usr or /usr/local if you like, but
using /opt this way lets me easily have multiple versions and ports
of wxWindows "installed" and makes it easy to switch between them,
without impacting any versions of wxWindows that may have been
installed via an RPM or whatever. For the rest of the steps below
be sure to also substitute "/opt/wx/2.5" with whatever prefix you
choose for your build.
If you want to use the image and zlib libraries included with
wxWindows instead of those already installed on your system, (for
example, to reduce dependencies on 3rd party libraries) then you
can add these flags to the configure command::
--with-libjpeg=builtin \
--with-libpng=builtin \
--with-libtiff=builtin \
--with-zlib=builtin \
2. To build and install wxWindows you could just use "make" but there
are other libraries that also need to be built so again I make a
script to do it all for me so I don't forget anything. This time
it is called ".make" (I use the leading ". so when I do "rm -r *"
in my build dir I don't lose my scripts too.) This is what it
looks like::
2. To build and install wxWindows you could just use the "make"
command but there are other libraries besides the main wxWindows
libs that also need to be built so again I make a script to do it
all for me so I don't forget anything. This time it is called
".make" (I use the leading ". so when I do "rm -r *" in my build
dir I don't lose my scripts too.) This is what it looks like::
make $* \
&& make -C contrib/src/gizmos $* \
@ -95,8 +123,13 @@ place, then do the same for wxPython.
these commands, so it won't impact your already installed version
of the latest release. You'll be able test with this version when
you want to, and use the installed release version the rest of the
time. If you ever do want to install the development verison just
use the normal distutils commands to do it.
time. If do want to install the development verison please read
INSTALL.txt.
If you have more than one version of Python on your system then be
sure to use the version of Python that you want to use when running
wxPython programs to run the setup.py commands below. I'll be
using python2.3.
Make sure that the first wx-config found on the PATH is the one you
installed above, and then change to the wxWindows/wxPython dir and
@ -105,6 +138,12 @@ place, then do the same for wxPython.
cd wxPython
python2.3 setup.py build_ext --inplace --debug
If your new wx-config script is not on the PATH, or there is some
other version of it found first, then you can add this to the
command line to ensure your new one is used instead::
WX_CONFIG=/opt/wx/2.5/bin/wx-config
If you are building with GTK2 then add the following flags to the
command line::
@ -116,6 +155,11 @@ place, then do the same for wxPython.
USE_SWIG=1 SWIG=/opt/swig/bin/swig
If you get errors about wxGLCanvas or being unable to find libGLU
or something like that then you can add BUILD_GLCANVAS=0 to the
setup.py command line to disable the building of the glcanvas
module.
When the setup.py command is done you should have fully populated
wxPython and wx packages locally in wxWindows/wxPython/wxPython and
.../wx, with all the extension modules (*.so files) located in the
@ -130,6 +174,21 @@ place, then do the same for wxPython.
cd /myprojects/wxWindows/wxPython/demo
python2.3 demo.py
OS X NOTE: You need to use "pythonw" on the command line to run
wxPython applications. This version of the Python executable is
part of the Python Framework and is allowed to interact with the
display. You can also Double Click on a .py or a .pyw file from
the finder (assuming that PythonLauncher is still associated with
these file extensions) and it will launch the Framework version of
Python for you. For information about creating Applicaiton Bundles
of your wxPython apps please see the wiki and the mail lists.
SOLARIS NOTE: If you get unresolved symbol errors when importing
wxPython and you are running on Solaris and building with gcc, then
you may be able to work around the problem by uncommenting a bit of
code in setup.py and building again. Look for 'SunOS' in setup.py
and uncomment the block containing it. The problem is that Sun's ld
does not automatically add libgcc to the link step.
@ -148,8 +207,8 @@ using VisualStudio.Net (a.k.a. MSVC 7.1) keep in mind that you'll also
have to build Python and any other extension modules that you use with
that compiler because a different version of the C runtime likbrary is
used. The Python executable that comes from PythonLabs and the
wxPythons that I distribute are built with MSVC 6 with all the Service
Packs applied.
wxPython extensions that I distribute are built with MSVC 6 with all
the Service Packs applied.
If you want to build a debugable version of wxWindows and wxPython you
will need to have also built a debug version of Python and any other
@ -179,10 +238,11 @@ here. There is a copy of my build scripts in wxWindows\wxPython\distrib\msw
cd %WXWIN%\include\wx\msw
copy setup0.h setup.h
3. Edit setup.h and change a few settings. Some of them are changed
by my build scripts depending on the type of build (debug/hybrid,
unicode/ansi). I change a few of the other defaults to have these
values::
3. Edit %WXWIN%\include\wx\msw\setup.h and change a few settings.
Some of them are changed by my build scripts depending on the type
of build (debug/hybrid, unicode/ansi). I change a few of the other
defaults to have these values::
wxDIALOG_UNIT_COMPATIBILITY 0
wxUSE_DEBUG_CONTEXT 1
@ -196,10 +256,12 @@ here. There is a copy of my build scripts in wxWindows\wxPython\distrib\msw
4. Make a %WXWIN%\BIN directory and add it to the PATH. My build
scripts will copy the wxWindows DLLs there.
5. Change to the %WXWIN%\build\msw directory and copy my build scripts
there.
6. Use the .make command to build wxWindows. It needs one
6. Use the .make.btm command to build wxWindows. It needs one
command-line parameter which controls what kind of build(s) to do.
Use one of the following::
@ -214,21 +276,30 @@ here. There is a copy of my build scripts in wxWindows\wxPython\distrib\msw
.make hybrid
You can also pass additional command line parameters as needed and
they will all be passed on to the nmake commands, for example to
clean up the build::
7. When that is done there should be a ton of DLLs in %WXDIR%\bin and
lots of lib files and stuff in %WXDIR%\lib\vc_dll
.make hybrid clean
7. When that is done it will have built the main wxWindows DLLs and
also some of the contribs DLLs. There should be a ton of DLLs in
%WXDIR%\bin and lots of lib files and other stuff in
%WXDIR%\lib\vc_dll.
8. Building wxPython on Windows is very similar to doing it for the
unix systems. We're not going to install the development version
of wxPython with these commands, so it won't impact your already
installed version of the latest release. You'll be able test with
this version when you want to, and use the installed release
installed version of the latest release. You'll be able to test
with this version when you want to, and use the installed release
version the rest of the time. If you ever do want to install the
development verison just use the normal distutils commands to do
it.
development verison please refer to INSTALL.txt.
Change to the wxWindows\wxPython dir and run the this command::
Change to the wxWindows\wxPython dir and run the this command,
makeing sure that you use the version of python that you want to
build for (if you have more than one on your system)::
cd %WXWIN%\wxPython
python setup.py build_ext --inplace
@ -239,16 +310,21 @@ here. There is a copy of my build scripts in wxWindows\wxPython\distrib\msw
USE_SWIG=1 SWIG=e:\projects\SWIG-cvs\swig.exe
If you built a Unicode version of wxWindows and want to also build
the Unicode version of wxPython then add this flag::
UNICODE=1
If you have a debug version of Python and wxWindows and want to
build a debug version of wxPython too, add the --debug flag to the
command line. You should then end up with a set of *_d.pyd files
in the wx package and you'll have to use python_d.exe to use them.
in the wx package and you'll have to run python_d.exe to use them.
The debug and hybrid(release) versions can coexist.
When the setuyp.py command is done you should have fully populated
wxPython and wx packages locally in wxWindows/wxPython/wxPython and
.../wx, with all the extension modules (*.pyd files) located in the
wx package.
wxWindows/wxPython/wx, with all the extension modules (*.pyd files)
located in the wx package.
9. To run code with the development verison of wxPython, just set the
@ -258,3 +334,4 @@ here. There is a copy of my build scripts in wxWindows\wxPython\distrib\msw
cd e:\projects\wxWindows\wxPython
python demo.py

340
wxPython/docs/BUILD.unix.txt
View File

@ -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=<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

303
wxPython/docs/BUILD.win32.txt
View File

@ -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=<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

133
wxPython/docs/INSTALL.txt Normal file
View File

@ -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=<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