Lerking/Phoenix
1
0
Fork 0
mirror of https://github.com/wxWidgets/Phoenix.git synced 2025-12-16 09:40:07 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

More text updates in the README and setup.py descriptions

Browse Source
This commit is contained in:
Robin Dunn
2017-04-07 12:27:02 -07:00
parent 8c79e98b57
commit f10e966484
2 changed files with 55 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files

93
README.rst
View File

@@ -9,34 +9,33 @@ wxPython Project Phoenix
Introduction
------------
Welcome to wxPython's Project Phoenix! This project is a new implementation
of wxPython focused on improving speed, maintainability and extensibility.
Just like "Classic" wxPython it wraps the wxWidgets C++ toolkit and provides
access to the user interface portions of the wx API, enabling Python
applications to have a GUI on Windows, Macs or Unix systems with a native
look and feel and requiring very little (if any) platform specific code.
See http://wiki.wxpython.org/ProjectPhoenix for more information about this
project and information about how you can help out.
Welcome to wxPython's Project Phoenix! Phoenix is the improved next-generation
wxPython, "better, stronger, faster than he was before." This new
implementation is focused on improving speed, maintainability and
extensibility. Just like "Classic" wxPython, Phoenix wraps the wxWidgets C++
toolkit and provides access to the user interface portions of the wxWidgets
API, enabling Python applications to have a native GUI on Windows, Macs or
Unix systems, with a native look and feel and requiring very little (if any)
platform specific code.
.. contents:: **Contents**
How to build Phoenix
--------------------
How to build wxPython Phoenix
-----------------------------
First of all, review the section below about prerequisites.
All aspects of the Phoenix build are managed through a series of commands
provided by the build.py script. There is also a setup.py script available
for those who are used to the standard distutils or setuptools types of
builds. The setup.py script assumes that all of the code generation steps
All aspects of the wxPython Phoenix build are managed through a series of
commands provided by the build.py script. There is also a setup.py script
available for those who are used to the standard distutils or setuptools types
of builds. The setup.py script assumes that all of the code generation steps
have already been performed, and so it is suitable for use when building from
a source snapshot tarball or when using easy_install or pip. The setup.py
script will delegate to build.py for the actual build, and build.py will
delegate to setup.py when doing setuptoolsy things like performing an install
or building an egg.
or building a wheel.
Using the build.py script allows for greater control over the build process
than setup.py does, including commands for performing the various
@@ -93,9 +92,9 @@ details. However be aware that doing so will require a wxWidgets that is
unreleased preview snapshots. In other words, the wxWidgets build should use
code from the wxWidgets source repository within a few days of when the
Phoenix code was checked out. Currently Phoenix is expecting to be used with
a wxWidgets built from the ``wxPy-3.0-branch`` git branch.
a wxWidgets built from the ``WX_3_0_BRANCH`` git branch.
On the other hand, it is probably best to just let Phoenix build and bundle
On the other hand, it is probably best to just let wxPython build and bundle
wxWidgets. The build tools will by default build wxWidgets in a way that
allows it to be bundled with the wxPython extension modules as part of the
wxPython package, meaning it can peacefully coexist with any wxWidgets
@@ -114,11 +113,11 @@ The build phase of the build.py script will copy the results of the wxWidgets
and Phoenix builds into the wx folder in the Phoenix source tree. This will
allow you to run and test Phoenix directly from the source tree without
installing it, if desired. You just need to set ``PYTHONPATH`` appropriately,
or you can use ``python setup.py develop`` to install an .egg-link file in
your current Python site-packages folder that will point to the folder where
you built Phoenix. When you are finished testing you can then use the install
or one of the bdist commands like you normally would for other Python
packages.
or you can use ``python setup.py develop`` or ``pip install -e .`` to install
an .egg-link file in your current Python site-packages folder that will point
to the folder where you built wxPython Phoenix. When you are finished testing
you can then use the install or one of the bdist commands like you normally
would for other Python packages.
@@ -129,7 +128,7 @@ The following ``build.py`` commands are required to be able to build Phoenix
from scratch. In other words, from a pristine source tree with none of the
generated code present yet. They can be run individually or you can specify
all of them on a single command line, in the order given. Once a command has
succeded in one run of build.py there is no need to run that command again in
succeeded in one run of build.py there is no need to run that command again in
a later run, unless you've changed something which that command has the
responsibility to process. Many of the commands require the results of the
earlier commands, so at least the first time you run the build you will need
@@ -173,20 +172,20 @@ Some other useful commands and options are:
handy for things like buildbots running in a virtualenv for one Python
that need to be able to run builds for other versions too.
If build.py is still not able to find the correct Python given the M.N
on the command line then you can specify the full path to the python
executable you want to use with the ``--python`` option.
If build.py is not able to find the correct Python given the M.N on the
command line then you can specify the full path to the python executable you
want to use with the ``--python`` option.
* **test**: Runs all of Phoenix's unittests.
* **--nodoc**: This option turns off the sphinx generator when running the
etg scripts. If you don't plan on generating the documentation then this
will speed up the proccessing of the etg command.
will speed up the processing of the etg command.
Please see the output of ``python build.py --help`` for information about
commands and options not mentioned here. And, as always, if there is any
discrepancy between this document and the source code in the build.py script,
then the source code is right. ;-)
then the source code is correct. ;-)
The build.py script will download doxygen, sip and waf for your platform as
needed if they are not already in your Phoenix/bin folder. If prebuilt
@@ -233,10 +232,9 @@ explanation to help a newbie find their way around.
from build.py and setup.py and which assist with configuring and running
the build.
* **etg**: This is where the Extractor-Tweaker-Generator scripts are stored
(see the ProjectPhoenix link above.) These scripts are invoked by the build
and they will read the XML files produced by Doxygen and will produce
interface definition files for SIP.
* **etg**: This is where the "Extractor-Tweaker-Generator" scripts are stored.
These scripts are invoked by the build and they will read the XML files
produced by Doxygen and will produce interface definition files for SIP.
* **etgtools**: This Python package contains modules which assist with the
parsing of the XML files, tweaking the collection of objects produced by
@@ -259,7 +257,7 @@ explanation to help a newbie find their way around.
* **sip/cpp**: The code produced when running SIP is put in this folder. It
will be C++ source and header files, and also some extra files with
information about the source files produced so the build knows what files
information about the source files produced, so the build knows what files
to compile.
* **sip/siplib**: This is a copy of the SIP runtime library. We have our
@@ -286,18 +284,18 @@ Naming of files
To help keep things a little easier when looking for things that need to be
worked on, the file names in the Phoenix project will mirror the names of the
files in the wxWidgets interface headers folder. For example, if there is a
interface/wx/FOO.h and we are processing the XML produced for that file then
the ETG script for the classes and other items will be named etg/FOO.py and it
will produce sip/gen/FOO.sip, unit tests will be in unittests/test_FOO.py,
and so on.
``interface/wx/FOO.h`` and we are processing the XML produced for that file
then the ETG script for the classes and other items will be named
``etg/FOO.py`` and it will produce ``sip/gen/FOO.sip``, unit tests will be in
``unittests/test_FOO.py``, and so on.
In most cases more than one ETG/SIP file will be used to create a single
Python extension module. In those cases there will be one ETG script used to
bring all the others together into the single extension module (by using the
back-end generator's include feature for example.) The names of those scripts
will have a leading underscore, such as etg/_core.py, and all the scripts that
are intended to be included in that extension module should specify that name
in their MODULE variable.
will have a leading underscore, such as ``etg/_core.py``, and all the scripts
that are intended to be included in that extension module should specify that
name in their MODULE variable.
Prerequisites
@@ -313,7 +311,7 @@ a PR for updating this document.
All the source code needed for wxWidgets and wxPython Phoenix are
included in the wxWidgets and Phoenix source trees. In addition to a
stock Python installation you will also need a copy of Visual Studio 2008
(for Python2.7 compatibility) or Visual Studio 2010 (for Python 3.x
(for Python2.7 compatibility) or Visual Studio 2015 (for Python 3.x
support). It should also be possible to build using Mingw32, but there
will need to be some changes made to the build scripts to support that.
@@ -321,10 +319,10 @@ You may also want to get a copy of the MS SDK in order to have newer
definitions of the Windows API. I typically use 7.0 or 7.1 with Visual
Studio 2008.
Unfortunately Microsoft no longer distributes Visual Studio 2008. But
don't panic! They have recently made available a "Microsoft Visual C++
Compiler for Python 2.7" package. I haven't tried it but I expect it will
work fine for building Phoenix. Plus it's free! You can get it at:
Unfortunately Microsoft no longer distributes Visual Studio 2008. But don't
panic! They have recently made available a "Microsoft Visual C++ Compiler for
Python 2.7" package, which can also be used for building Phoenix for Python
2.7. Plus it's free! You can get it at:
http://www.microsoft.com/en-us/download/details.aspx?id=44266
If you want to build Phoenix with debug info then you will need to first
@@ -369,8 +367,7 @@ Also like on Windows, using the same or similar compiler that was used to
build Python usually helps things to work better and have a better chance
for success. For example, the stock Python 2.7 will try to use "gcc-4.2"
when building extensions, but newer versions of Xcode may not have that
command available. I am currently using Xcode 4.6.3, and I have symlinks
in ``/usr/local/bin`` pointing to the ``/usr/bin/llvm-*-4.2`` executables.
command available. I am currently using Xcode 7.1.1.
If all else fails it is not too hard to build Python yourself using
whatever Xcode you have installed, and then use that Python when building

19
setup.py
View File

@@ -30,7 +30,7 @@ import buildtools.version as version
#----------------------------------------------------------------------
NAME = version.PROJECT_NAME
DESCRIPTION = "Cross platform GUI toolkit for Python, Phoenix version"
DESCRIPTION = "Cross platform GUI toolkit for Python, \"Phoenix\" version"
AUTHOR = "Robin Dunn"
AUTHOR_EMAIL = "Robin Dunn <robin@alldunn.com>"
URL = "http://wxPython.org/"
@@ -42,19 +42,20 @@ PLATFORMS = "WIN32,WIN64,OSX,POSIX"
KEYWORDS = "GUI,wx,wxWindows,wxWidgets,cross-platform,awesome"
LONG_DESCRIPTION = """\
{name} is the new and improved wxPython! This new implementation (known
internally as "wxPython Phoenix") is focused on improving speed,
maintainability and extensibility. Just like "Classic" wxPython it wraps the
wxWidgets C++ toolkit and provides access to the user interface portions of
the wxWidgets API, enabling Python applications to have a native GUI on
Windows, Macs or Unix systems with a native look and feel and requiring very
little (if any) platform specific code.
Welcome to wxPython's Project Phoenix! Phoenix is the improved next-generation
wxPython, "better, stronger, faster than he was before." This new
implementation is focused on improving speed, maintainability and
extensibility. Just like "Classic" wxPython, Phoenix wraps the wxWidgets C++
toolkit and provides access to the user interface portions of the wxWidgets
API, enabling Python applications to have a native GUI on Windows, Macs or
Unix systems, with a native look and feel and requiring very little (if any)
platform specific code.
For more information please refer to the
`README file <https://github.com/wxWidgets/Phoenix/blob/master/README.rst>`_,
the `Migration Guide <https://wxpython.org/Phoenix/docs/html/MigrationGuide.html>`_,
or the `wxPython API documentation <https://wxpython.org/Phoenix/docs/html/main.html>`_.
""".format(name=NAME)
"""
# or maybe LONG_DESCRIPTION=open("README.rst").read() ??