From 29ad9f3baf3540a82c008d66373e7e8534aff5a6 Mon Sep 17 00:00:00 2001 From: Luciano Wolf Date: Thu, 29 Apr 2010 15:14:05 -0300 Subject: Update shiboken documentation. --- doc/_templates/index.html | 4 +- doc/compiling.rst | 2 +- doc/contents.rst | 1 + doc/faq.rst | 22 +- doc/tutorial/bindinglibfoo.rst | 77 ++++++ doc/tutorial/buildingthebinding.rst | 131 ++++++++++ doc/tutorial/globalheader.rst | 36 +++ doc/tutorial/images/generatorworkings.png | Bin 0 -> 37257 bytes doc/tutorial/images/generatorworkings.svg | 392 ++++++++++++++++++++++++++++++ doc/tutorial/introduction.rst | 32 +++ doc/tutorial/libfoo.rst | 69 ++++++ doc/tutorial/typesystemcreation.rst | 136 +++++++++++ 12 files changed, 892 insertions(+), 10 deletions(-) create mode 100644 doc/tutorial/bindinglibfoo.rst create mode 100644 doc/tutorial/buildingthebinding.rst create mode 100644 doc/tutorial/globalheader.rst create mode 100644 doc/tutorial/images/generatorworkings.png create mode 100644 doc/tutorial/images/generatorworkings.svg create mode 100644 doc/tutorial/introduction.rst create mode 100644 doc/tutorial/libfoo.rst create mode 100644 doc/tutorial/typesystemcreation.rst (limited to 'doc') diff --git a/doc/_templates/index.html b/doc/_templates/index.html index 09486d7ee..cdbdee9b7 100644 --- a/doc/_templates/index.html +++ b/doc/_templates/index.html @@ -4,7 +4,7 @@

{{ project }} {{ version }}

-

{{ project }} is a plugin for Generator Runner, this generator generates CPython code instead of boost::python code as BoostPythonGenerator does.

+

{{ project }} is a plugin (front-end) for Generator Runner. It generates CPython code instead of boost::python code as BoostPythonGenerator does. This way the overall size of PySide bindings can be drastically reduced.

Documentation

@@ -13,6 +13,8 @@ for a complete overview

FAQ
answers for frequent asked questions

+

Tutorial
+ start here

Command line options
explains the few flags used to change {{ project }} behaviour

Type System Variables
diff --git a/doc/compiling.rst b/doc/compiling.rst index d9ce2be4d..7958d573b 100644 --- a/doc/compiling.rst +++ b/doc/compiling.rst @@ -18,5 +18,5 @@ Building and installing ^^^^^^^^^^^^^^^^^^^^^^^ To build and install just follow the generic cmake instructions in -section cmake-primer. +section `cmake-primer `_. diff --git a/doc/contents.rst b/doc/contents.rst index 85751f6fc..f7fb39b8c 100644 --- a/doc/contents.rst +++ b/doc/contents.rst @@ -5,6 +5,7 @@ Table of contents :maxdepth: 3 faq.rst + tutorial/introduction.rst commandlineoptions.rst typesystemvariables.rst codeinjectionsemantics.rst diff --git a/doc/faq.rst b/doc/faq.rst index e854f4360..77e0fbdfc 100644 --- a/doc/faq.rst +++ b/doc/faq.rst @@ -11,11 +11,17 @@ General What is Shiboken? ----------------- -Shiboken is a GeneratorRunner plugin that outputs C++ code for CPython extensions. +Shiboken is a `GeneratorRunner `_ +plugin that outputs C++ code for CPython extensions. The first version of PySide +had source code based on Boost templates. It was easier to produce code but a +paradigm change was needed, as the next question explains. -Here the name generator refers actually to a program composed of a set of -*generator classes* that output different resources based on information -contained inside C++ header files. +Why did you switch from Boost.Python to Shiboken? +------------------------------------------------- + +The main reason was the size reduction. Boost.Python makes excessive use of templates +resulting in a significant increase of the binaries size. On the other hand, as Shiboken +generates CPython code, the resulting binaries are smaller. Creating bindings ================= @@ -38,10 +44,10 @@ What do I have to do to create my bindings? .. todo: put link to typesystem documentation Most of the work is already done by the API Extractor. The developer creates -a typesystem file with any customization wanted in the generated code, like -removing classes or changing method signatures. The generator will output -the .h and .cpp files with the CPython code that will wrap the target -library for python. +a `typesystem `_ file +with any customization wanted in the generated code, like removing classes or +changing method signatures. The generator will output the .h and .cpp files +with the CPython code that will wrap the target library for python. Is there any recommended build system? -------------------------------------- diff --git a/doc/tutorial/bindinglibfoo.rst b/doc/tutorial/bindinglibfoo.rst new file mode 100644 index 000000000..b12e53f0c --- /dev/null +++ b/doc/tutorial/bindinglibfoo.rst @@ -0,0 +1,77 @@ +.. highlight:: xml + +.. _gentut-bindinglibfoo: + +Binding libfoo using Shiboken +============================= + +In order to create bindings for a library based on Qt4 a number of components +must be available on the system. + + + Qt4 library (with headers and pkg-config .pc files for development -- the + ``-dev`` packages in a Debian distribution). + + Qt4 Python bindings made with :program:`shiboken`. + + Typesystems for the Qt4 Python bindings. + + Headers for the library to be bound. + +With the items listed above the developer must write the components from +where the generator will gather information to create the binding source code. + + + Typesystem file describing the way the binding must be done. + + **global.h** including all the **libfoo** headers and defining required macros. + + A build system to direct the process of generating, compiling and linking the + binding. + +The directory structure for the binding project could be something like the tree +shown below: + +:: + + foobinding/ + |-- data/ + `-- module_dir/ + `-- glue/ + + +The **data** directory should contain the **global.h** and the typesystem +file. This typesystem need to refer to the ones used to create the Qt4 bindings, +commonly located on **/usr/share/PySide/typesystem**, the exact location +can be checked with pkg-config: + +:: + + $ pkg-config pyside --variable=typesystemdir + + +The **module_dir** directory is the place where the sources generated should +be placed. It starts empty except for the build instructions file (Makefile, +Makefile.am, CMakeLists.txt, etc). The realname of this directory must be the +same written in the typesystem file: + +:: + + + + +If there is any need for handwritten source code longer than a couple of lines, +making them unconfortable to be put on the typesystem xml file, the sources +could be orderly placed in a **glue** directory, also referred in the +new binding typesystem. + +When writing the typesystem file (more on this later) there is no need to refer +to the other required typesystem files with absolute paths, the locations where +they can be found could be passed to the generator through a command line +option (``--typesystem-paths=PATH1:PATH2:[...]``) or the environment variable +**TYPESYSTEMPATH**. + +For **libfoo** no glue code will be needed so this directory is not used, +the other directories are created with proper names. + +:: + + foobinding/ + |-- data/global.h + | `-- typesystem_foo.xml + `-- foo/ + `-- Makefile + diff --git a/doc/tutorial/buildingthebinding.rst b/doc/tutorial/buildingthebinding.rst new file mode 100644 index 000000000..d03010ca4 --- /dev/null +++ b/doc/tutorial/buildingthebinding.rst @@ -0,0 +1,131 @@ +.. _gentut-buildingthebinding: + +Building The Binding +==================== + +As mentioned before the build system used must perform the following tasks +in the correct order: + + + Gather data about locations of headers and external needed typesystems. + + Run the generator with the correct parameters. + + Compile and link the binding. + +The first and last are the usual, being the second the only novelty in the +process. + +Running the Generator +--------------------- + +The generator is called with the following parameters and options: + +:: + + $ generatorrunner --generatorSet=shiboken \ + global_headers.h \ + --include-paths=$(PATHS_TO_HEADERS)) \ + --typesystem-paths=$(PATHS_TO_TYPESYSTEMS) \ + --output-directory=. \ + typesystem.xml + +Notice that the variables for include and typesystem paths could be determined +at build time with the pkg-config tool. + +Collecting information with pkg-config +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The Qt4 bindings include compile and build information through the pkg-config +mechanism. The pkg-config name for Qt4 Python bindings is **pyside** and a +simple ``pkg-config pyside --cflags --libs`` will retrieve the information +needed to build the new binding. + +The Qt4 bindings file ``pyside.pc`` for the use of pkg-config requires +the ``.pc`` files from Qt4 to be installed. If the library is in an unusual +location, e.g. ``/opt/qt46``, remember to export it to the ``PKG_CONFIG_PATH`` +environment variable. +For example: ``export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/qt46/lib/pkgconfig`` + +There is a vital information also available through pkg-config: +the **typesystemdir** variable. It is used like this: +``pkg-config pyside --variable=typesystemdir`` This provides information +where to find the typesystem files used to create the Qt4 bindings, and as said +before the binding being created needs this to complement its own binding +information for the generation proccess. + +Makefile +-------- + +Below is a plain Makefile for the binding project. + +**foobinding/foo/Makefile** +:: + + LIBFOO_DIR = ../../libfoo + LIBS = `python-config --libs` \ + -lpyside \ + -lfoo -L$(LIBFOO_DIR) + CXXFLAGS = -I/usr/share/qt4/mkspecs/linux-g++ -I. \ + -I$(LIBFOO_DIR) \ + -I`pkg-config --variable=includedir pyside`/QtCore/ \ + -I`pkg-config --variable=includedir QtCore` \ + -I`pkg-config --variable=includedir QtGui` \ + -I`pkg-config --variable=includedir QtCore`/.. \ + -I`python-config --includes` \ + `pkg-config pyside --cflags` \ + `pkg-config shiboken --cflags` + + QT4TYPESYSTEM_DIR = "/usr/share/PySide/typesystem/" + QT4HEADER_DIRS = `pkg-config --variable=includedir QtCore`:`pkg-config --variable=includedir QtCore`/.. + + SOURCES = foo_module_wrapper.cpp math_wrapper.cpp + OBJECTS = foo_module_wrapper.o math_wrapper.o + + all: generate compile link + + generate: + generatorrunner --generatorSet=shiboken \ + ../data/global.h \ + --include-paths=$(LIBFOO_DIR):$(QT4HEADER_DIRS):/usr/include \ + --typesystem-paths=../data:$(QT4TYPESYSTEM_DIR) \ + --output-directory=.. \ + ../data/typesystem_foo.xml + + compile: $(SOURCES) + g++ -Wall -fPIC -DPIC $(CXXFLAGS) -c foo_module_wrapper.cpp + g++ -Wall -fPIC -DPIC $(CXXFLAGS) -c math_wrapper.cpp + + link: + g++ -shared -Wl,-soname,foo.so -o foo.so $(LIBS) $(OBJECTS) + + test: + LD_LIBRARY_PATH=$(LIBFOO_DIR):$LD_LIBRARY_PATH python -c \ + "import PySide.QtCore; import foo; print dir(foo); m = foo.Math(); print \"5 squared is %d\" % m.squared(5)" + + clean: + rm -rf *.o *.so *.?pp *.log *.h + +Keep in mind that the Makefile above expects the ``libfoo`` and +``foobinding`` directories to be in the same level in the directory +hierarchy, remember to change any path references accordingly if +you choose to change things. + +Testing the Binding +------------------- +Now compile the binding with ``make``: + +:: + + $ cd foobinding/foo + $ make + +To test if the new binding is working (it can pass the build phase but still +blow up at runtime) start up a Python terminal and import it by the name. + +:: + + $ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/libfoo/shared/object/dir + $ export PYTHONPATH=$PYTHONPATH:/path/to/foo/python/module/file/dir + $ python + >> import foo + >> print dir(foo) + >> m = foo.Math() + >> print m.squared(5) diff --git a/doc/tutorial/globalheader.rst b/doc/tutorial/globalheader.rst new file mode 100644 index 000000000..7e853f8c2 --- /dev/null +++ b/doc/tutorial/globalheader.rst @@ -0,0 +1,36 @@ +.. highlight:: cpp + +.. _gentut-globalheader: + +The Global Header +================= + +Besides the information provided by the typesystem, the generator needs to +gather more data from the library headers containing the classes to be exposed +in Python. If there is a header that include all the others (or just one, as is +the case of **libfoo**) this could be passed directly to the generator. + +If such a file is not available, or only a subset of the library is desired, or +if some flags must be defined before parsing the library headers, then a +``global.h`` file must be provided. + +The use of a ``global.h`` file is preferred if some macros must be defined +before the parser gather data from the headers. For example, if ``NULL`` is not +defined and it is used as a default paramater for some constructor or method, +the parser will not recognize it. + +To solve this create a ``global.h`` including all the desired headers and the +defined (and undefined) flags as follows: + +**foobinding/data/global.h** +:: + + #undef QT_NO_STL + #undef QT_NO_STL_WCHAR + + #ifndef NULL + #define NULL 0 + #endif + + #include + diff --git a/doc/tutorial/images/generatorworkings.png b/doc/tutorial/images/generatorworkings.png new file mode 100644 index 000000000..d35a565ff Binary files /dev/null and b/doc/tutorial/images/generatorworkings.png differ diff --git a/doc/tutorial/images/generatorworkings.svg b/doc/tutorial/images/generatorworkings.svg new file mode 100644 index 000000000..85a7782af --- /dev/null +++ b/doc/tutorial/images/generatorworkings.svg @@ -0,0 +1,392 @@ + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + bindingsource code + + + + + + + typesystemdescriptions + + + + customsourcecode + + + + + + libraryheaders + + + + + + Parser + + + + GeneratorBackend + + + + TypeDatabase + + + + + diff --git a/doc/tutorial/introduction.rst b/doc/tutorial/introduction.rst new file mode 100644 index 000000000..40240f80a --- /dev/null +++ b/doc/tutorial/introduction.rst @@ -0,0 +1,32 @@ +Binding Generation Tutorial +*************************** + +This tutorial intends to describe the process of binding creation with +Shiboken and using a very simple Qt4 based library will be used as an +example. + +The image below shows the inputs needed to generate the binding source code. + +.. image:: images/generatorworkings.png + +Putting in words, the user provides the headers for the library along with a +`typesystem `_ file +describing how the classes will be exposed in the target language, as well as +any needed custom source code to be merged with the generated source code. + +This tutorial will go through the steps needed to have the binding +ready to be imported and used from a Python program. The tutorial +source code is available as a tar ball `here <../_static/bindingexample.tar.gz>`_. + +**NOTE:** the binding generator is intended to be used with Qt4 based libraries +only, at least for the time being. + +.. toctree:: + :maxdepth: 3 + + libfoo + bindinglibfoo + typesystemcreation + globalheader + buildingthebinding + diff --git a/doc/tutorial/libfoo.rst b/doc/tutorial/libfoo.rst new file mode 100644 index 000000000..bad6b014a --- /dev/null +++ b/doc/tutorial/libfoo.rst @@ -0,0 +1,69 @@ +.. highlight:: cpp + +.. _gentut-libfoo: + +Creating the foo library +========================= + +In this section it will be presented the code and the build instructions for a +very simple Qt4 based library. It will be used as the subject for this tutorial. + +The Source Code +--------------- + +There is only one class on this foo library plus a ``.pro`` file which means +that the build system used will be `qmake `_ +based. + +Put the files below in a directory called **libfoo**. Be aware that this +directory will be referred by the binding Makefile presented in a next section +of this tutorial. If you want to use other names or paths change the binding +Makefile accordingly. Blind copy'n'paste shortens your life. + +**libfoo/foo.h** +:: + + #ifndef FOO_H + #define FOO_H + + #include + + class Math : public QObject + { + Q_OBJECT + public: + Math() {} + virtual ~Math() {} + int squared(int x); + }; + #endif // FOO_H + + +**libfoo/foo.cpp** +:: + + #include "foo.h" + + int Math::squared(int x) + { + return x * x; + } + + +**libfoo/foo.pro** +:: + + TEMPLATE = lib + TARGET = foo + DEPENDPATH += . + INCLUDEPATH += . + HEADERS += foo.h + SOURCES += foo.cpp + +To build the lib: + +:: + + $ cd libfoo + $ qmake + $ make diff --git a/doc/tutorial/typesystemcreation.rst b/doc/tutorial/typesystemcreation.rst new file mode 100644 index 000000000..538222337 --- /dev/null +++ b/doc/tutorial/typesystemcreation.rst @@ -0,0 +1,136 @@ +.. highlight:: xml + +.. _gentut-typesystem: + +Creating the Typesystem Description +=================================== + +The typesystem is an specification used when mapping a C++ based library onto a +corresponding Python module. The specification is a handwritten XML document +listing the types that will be available in the generated binding, modifications +to classes and function signatures to better suit the target language, +and listing the components that should be rejected for the binding. + +**PySide** uses a typesystem format similar to the one used by **QtJambi** and +**QtScript**, thoroughly described in the page *"The Qt Jambi Type System"*. [#]_ + +The divergences between **PySide** and QtScript/QtJambi typesystems will be +highlighted whenever they appear. Things to be aware of when writing +a typesystem will be also mentioned. + +Describing **libfoo** for Python Audiences +------------------------------------------ + +All typesystem files start with the root ``typesystem`` tag. The +``package`` attribute carries the name of the package as it will be seen +from Python. + +Right after that, all the typesystem files providing information required for +the generation process are included in the same fashion as header files in C. + +**foobinding/data/typesystem_foo.xml** +:: + + + + + + + + +The inclusion of other typesystem files is achieved with the +``load-typesystem`` tag. The ``generate`` attribute must be set to ``"no"`` +otherwise the generator will try to create more source code for the already +existing bindings included for reference. + +The C++ classes derived from **QObject** intended to be exposed in the target +language are described with ``object-type`` tags. + + +For this example binding just specifying the name of the class does the trick, +since the generator system will automatically catch the methods with arguments +and return value of known types. These types can be described in the same +typesystem file or in the ones referenced with the ``load-typesystem`` tag. + +In more complex situations method signatures can be changed or rejected with +other tags that can be checked out in the `typesystem `_ +reference. + + +Other Common Cases and Differences +---------------------------------- + +What follows now is some common uses of the typesystem capabilities. All of them +can be seen in the Qt4 typesystem files. They are not used for this binding +tutorial example, so if you just want to have things working ASAP, move along. + +Templates +~~~~~~~~~ + +To ease the process of writing custom code for the binding, recurring pieces of +code can be turned generic with the typesystem template mechanism. +They are declared in a way similar to this snippet: + +:: + + + +And is used as in this example: + +:: + + + + + + +The ``typesystem_template.xml`` file from the Qt4 bindings can be used as a +good resource for examples of this. Check also the QtJambi documentation on +typesystem templates. [#]_ + +Non-QObject Derived Classes +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Even in a Qt4 based library it is common to find classes that doesn't +pertain to the QObject hierarchy, these must be declared as ``value-type``: + +:: + + + + +Unused Tags +~~~~~~~~~~~ + +Some tags defined in the QtScript/QtJambi typesystem has no effect in **PySide** +typesystem, they are: + + + conversion-rule + + argument-map + +Changes to ``"inject-code"`` Tag +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can pass a file name to the **inject-code** tag so the file contents will +be injected in the generated code. + +The ``class`` attribute value ``java`` was changed to ``target``, while +``native`` remained the same. + +Global Functions +~~~~~~~~~~~~~~~~ + +The BoostPythonGenerator supports global functions, you can also reject these functions using +the **rejection** tag like is done to reject classes. Just pass an empty string to +the class attribute. + +:: + + + + +.. [#] http://doc.trolltech.com/qtjambi-4.4/html/com/trolltech/qt/qtjambi-typesystem.html +.. [#] http://doc.trolltech.com/qtjambi-4.4/html/com/trolltech/qt/qtjambi-typesystem.html#using-code-templates -- cgit v1.2.3