Docs updates for 2.5.3.0
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@29887 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Robin Dunn
parent
db301e681f
commit
4efdef2c87
@ -5,7 +5,7 @@ This file describes how I build wxWidgets 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://wxWidgets.org/snapshots/, a checkout from CVS, or
|
||||
one of the released wxPythonSrc-2.5.* tarballs. I'll also assume that
|
||||
one of the released wxPython-src-2.5.* tarballs. I'll also assume that
|
||||
you know your way around your system, the compiler, etc. and most
|
||||
importantly, that you know what you are doing! ;-)
|
||||
|
||||
@ -21,31 +21,31 @@ may already have installed.
|
||||
.. _INSTALL: INSTALL.html
|
||||
.. _BUILD: BUILD.html
|
||||
|
||||
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.
|
||||
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,
|
||||
plus some patches. Get the sources for version 1.3.22, and then apply
|
||||
the patches in wxPython/SWIG and then build SWIG like normal. See the
|
||||
README.txt in the wxPython/SWIG 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.
|
||||
|
||||
In the text below I'll use WXDIR with environment variable syntax
|
||||
(either $WXDIR or %WXDIR%) to refer to the top level directory were
|
||||
(either $WXDIR or %WXDIR%) to refer to the top level directory where
|
||||
your wxWidgerts and wxPython sources are located. It will equate to
|
||||
whereever you checked out the wxWidgets module from CVS, or untarred
|
||||
the wxPythonSrc tarball to. You can either substitute the $WXDIR text
|
||||
the wxPython-src tarball to. You can either substitute the $WXDIR text
|
||||
below with your actual dir, or set the value in the environment and
|
||||
use it just like you see it below.
|
||||
|
||||
If you run into what appears to be compatibility issues between
|
||||
wxWidgets and wxPython while building wxPython, be sure you are using
|
||||
the wxWidgets sources included with the wxPythonSrc tarball or the CVS
|
||||
snapshot, and not a previously installed version or a version
|
||||
the wxWidgets sources included with the wxPython-src tarball or the
|
||||
CVS snapshot, and not a previously installed version or a version
|
||||
installed from one of the standard wxWidgets installers. With the
|
||||
"unstable" releases (have a odd-numbered minor release value, where
|
||||
the APIs are allowed to change) there are often significant
|
||||
@ -86,23 +86,28 @@ place, then do the same for wxPython.
|
||||
On OS X of course you'll want to use --with-mac instead of
|
||||
--with-gtk.
|
||||
|
||||
**NOTE**: Due to a recent change there is a dependency problem in the
|
||||
multilib builds of wxWidgets on OSX, so I have switched to a
|
||||
monolithic build on that platform. (IOW, all of the core code in
|
||||
one shared library instead of several.) I would also expect other
|
||||
unix builds to do just fine with a monolithic library, but I havn't
|
||||
tested it in a while so your mileage may vary. Anyway, to switch
|
||||
**NOTE**: Due to a recent change there is currently a dependency
|
||||
problem in the multilib builds of wxWidgets on OSX, so I have
|
||||
switched to using a monolithic build. That means that all of the
|
||||
core wxWidgets code is placed in in one shared library instead of
|
||||
several. wxPython can be used with either mode, so use whatever
|
||||
suits you on Linux and etc. but use monolithic on OSX. To switch
|
||||
to the monolithic build of wxWidgets just add this configure flag::
|
||||
|
||||
--enable-monolithic \
|
||||
|
||||
By default GTK2 will be selected if it is on your build system. To
|
||||
force the use of GTK 1.2.x add this flag::
|
||||
By default GTK2 will be selected if its development pacakge is
|
||||
installed on your build system. To force the use of GTK 1.2.x
|
||||
instead add this flag::
|
||||
|
||||
--disable-gtk2 \
|
||||
|
||||
To make the wxWidgets build be Unicode enabled (strongly
|
||||
recommended if you are building with GTK2) then add::
|
||||
To make the wxWidgets build be unicode enabled (strongly
|
||||
recommended if you are building with GTK2) then add the following.
|
||||
When wxPython is unicode enabled then all strings that are passed
|
||||
to wx functions and methods will first be converted to unicode
|
||||
objects, and any 'strings' returned from wx functions and methods
|
||||
will actually be unicode objects.::
|
||||
|
||||
--enable-unicode \
|
||||
|
||||
@ -137,8 +142,7 @@ place, then do the same for wxPython.
|
||||
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 $*
|
||||
&& make -C contrib/src/stc $*
|
||||
|
||||
So you just use .make as if it where make, but don't forget to set
|
||||
the execute bit on .make first!::
|
||||
@ -268,6 +272,13 @@ 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.
|
||||
|
||||
Starting with 2.5.3.0 wxPython can be built for either the monlithic
|
||||
or the multi-lib wxWidgets builds. (Monolithic means that all the
|
||||
core wxWidgets code is in one DLL, and multi-lib means that the core
|
||||
code is divided into multiple DLLs.) To select which one to use
|
||||
specify the MONOLITHIC flag for both the wxWidgets build and the
|
||||
wxPython build as shown below, setting it to either 0 or 1.
|
||||
|
||||
Just like the unix versions I also use some scripts to help me build
|
||||
wxWidgets, but I use some non-standard stuff to do it. So if you have
|
||||
bash (cygwin or probably MSYS too) or 4NT plus unix-like cat and sed
|
||||
@ -361,7 +372,7 @@ accordingly if you are using the bash shell.
|
||||
executing nmake with a bunch of extra command line parameters.
|
||||
The base set are::
|
||||
|
||||
-f makefile.vc OFFICIAL_BUILD=1 SHARED=1 MONOLITHIC=0 USE_OPENGL=1
|
||||
-f makefile.vc OFFICIAL_BUILD=1 SHARED=1 MONOLITHIC=1 USE_OPENGL=1
|
||||
|
||||
If doing a debug build then add::
|
||||
|
||||
@ -381,7 +392,6 @@ accordingly if you are using the bash shell.
|
||||
contrib libraries::
|
||||
|
||||
%WXDIR%\contrib\build\gizmos
|
||||
%WXDIR%\contrib\build\xrc
|
||||
%WXDIR%\contrib\build\stc
|
||||
%WXDIR%\contrib\build\ogl
|
||||
|
||||
@ -404,10 +414,11 @@ accordingly if you are using the bash shell.
|
||||
|
||||
Change to the %WXDIR%\\wxPython dir and run the this command,
|
||||
making sure that you use the version of python that you want to
|
||||
build for (if you have more than one on your system)::
|
||||
build for (if you have more than one on your system) and to match
|
||||
the MONOLITHIC flag with how you built wxWidgets::
|
||||
|
||||
cd %WXDIR%\wxPython
|
||||
python setup.py build_ext --inplace
|
||||
python setup.py build_ext --inplace MONOLITHIC=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
|
||||
|
||||
@ -112,9 +112,9 @@ instructions above, except for a few small, but important details:
|
||||
you do yourself will end up in /Library/Frameworks even on
|
||||
Panther...
|
||||
|
||||
3. You need to use pythonw at the command line or PythonLauncher app
|
||||
to run wxPython apps, otherwise the app will not be able to fully
|
||||
use the GUI display.
|
||||
3. You need to use pythonw at the command line or the PythonLauncher
|
||||
app to run wxPython apps, otherwise the app will not be able to
|
||||
fully use the GUI display.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -786,6 +786,7 @@ The help module no longer exists and the classes therein are now part
|
||||
of the core module imported with wxPython.wx or the wx package.
|
||||
|
||||
|
||||
|
||||
wx.TaskBarIcon
|
||||
--------------
|
||||
|
||||
@ -821,9 +822,76 @@ and the MainLoop will not exit.
|
||||
|
||||
|
||||
|
||||
Version Number Change
|
||||
---------------------
|
||||
|
||||
Other Stuff
|
||||
-----------
|
||||
**[Changed in 2.5.3.x]**
|
||||
|
||||
Starting with 2.5.3.0 the Unicode versions of wxPython will no longer
|
||||
have a 'u' appended to the fourth component of the version number.
|
||||
Please check for the presence of "unicode" in the `wx.PlatformInfo`
|
||||
tuple instead. (This tuple of strings has been available since the
|
||||
first 2.5 version.) For example::
|
||||
|
||||
if "unicode" in wx.PlatformInfo:
|
||||
# do whatever
|
||||
...
|
||||
|
||||
|
||||
|
||||
|
||||
Multi-Version Installs
|
||||
----------------------
|
||||
|
||||
**[Changed in 2.5.3.x]**
|
||||
|
||||
Starting with 2.5.3.0 the wx and wxPython pacakge directories will be
|
||||
installed in a subdirectory of the site-packages directory, instead of
|
||||
directly in site-pacakges. This is done to help facilitate having
|
||||
multiple versions of wxPython installed side-by-side. Why would you
|
||||
want to do this? One possible scenario is you have an app that
|
||||
requires wxPython 2.4 but you want to use the newest 2.5 to do your
|
||||
development with. Or perhaps you want to be able to test your app
|
||||
with several different versions of wxPython to ensure compatibility.
|
||||
Before everyone panics, rest asured that if you only install one
|
||||
version of wxPython then you should notice no difference in how
|
||||
things work.
|
||||
|
||||
In addition to installing wxPython into a "versioned" subdirectory of
|
||||
site-packages, a file named `wx.pth` is optionally installed that will
|
||||
contain the name of the versioned subdirectory. This will cause that
|
||||
subdirectory to be automatically added to the sys.path and so doing an
|
||||
"import wx" will find the package in the subdirectory like like it
|
||||
would have if it was still located directly in site-packages. I say
|
||||
"optionally" above because that is how you can control which install
|
||||
of wxPython is the default one. Which ever version installs the
|
||||
wx.pth file will be the one that is imported with a plain "import wx"
|
||||
statement. Of course you can always manipulate that by editing the
|
||||
wx.pth file, or by setting PYTHONPATH in the environment, or by the
|
||||
method described in the next paragraph.
|
||||
|
||||
Finally, a new module named wxversion.py is installed to the
|
||||
site-pacakges directory. It can be used to manipulate the sys.path at
|
||||
runtime so your applications can select which version of wxPython they
|
||||
would like to to have imported. You use it like this::
|
||||
|
||||
import wxversion
|
||||
wxversion.require("2.4")
|
||||
import wx
|
||||
|
||||
Then eventhough a 2.5 version of wxPython may be the default the
|
||||
application that does the above the first time that wx is imported
|
||||
will actually get a 2.4 version. **NOTE:** There isn't actually a 2.4
|
||||
version of wxPython that supports this, but there will be.
|
||||
|
||||
Please see this wiki page for more details, HowTo's and FAQ's:
|
||||
http://wiki.wxpython.org/index.cgi/MultiVersionInstalls
|
||||
|
||||
|
||||
|
||||
|
||||
Miscellaneous Stuff
|
||||
-------------------
|
||||
|
||||
wxPyDefaultPosition and wxPyDefaultSize are gone. Use the
|
||||
wxDefaultPosition and wxDefaultSize objects instead.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user