The following diagram summarizes Shiboken’s role in the Qt for Python project.
An XML typesystem file is used to specify the types to be exposed to Python and to apply modifications to properly represent and manipulate the types in the Python World. For example, you can remove and add methods to certain types, and also modify the arguments of each method. These actions are inevitable to properly handle the data structures or types.
The final outcome of this process is a set of wrappers written in CPython, which can be used as a module in your Python code.
In a few words, the Generator is a utility that parses a collection of header and typesystem files, generating other files (code, documentation, etc.) as result.
Creating new bindings#
Each module of the generator system has an specific role.
Provide enough data about the classes and functions.
Generate valid code, with modifications from typesystems and injected codes.
Modify the API to expose the objects in a way that fits you target language best.
Insert customizations where handwritten code is needed.
The newly created binding will run on top of Shiboken which takes care of interfacing Python and the underlying C++ library.
Creating new bindings involves creating several pieces of “code”: the header, the typesystem and, in most cases, the injected code.
- header A header with
#includedirectives listing all the headers of the
desired classes. This header is not referenced by the generated code. Alternatively, it is possible to pass a list of the headers of the desired classes directly on the command line. In this case, the command line option
--use-global-headershould be passed as well to prevent the headers from being suppressed in the generated code.
- :typesystem: XML files that provides the developer with a tool to customize the
way that the generators will see the classes and functions. For example, functions can be renamed, have its signature changed and many other actions.
- :inject code: allows the developer to insert
handwritten code where the generated code is not suitable or needs some customization.
Command line options#
shiboken [options] header-file(s) typesystem-file
Disable verbose error messages. Turn the CPython code hard to debug but saves a few kilobytes in the generated binding.
This flag enable an useful heuristic which can save a lot of work related to object ownership when writing the typesystem. For more info, check Parentship heuristics.
Enable pyside extensions like support for signal/slots. Use this if you are creating a binding based on PySide.
Enable heuristics to detect parent relationship on return values. For more info, check Return value heuristics.
Avoid the use of the ‘#define protected public’ hack.
If a class has an isNull() const method, it will be used to compute the value of boolean casts (see Bool Cast).
Forward declare classes in module headers instead of including their class headers where possible.
If a class has an operator bool, it will be used to compute the value of boolean casts (see Bool Cast).
Do not generate implicit_conversions for function arguments.
Specify the supported api version used to generate the bindings.
Do not generate any code, just the documentation.
Semicolon separated list of type system entries (classes, namespaces, global functions and enums) to be dropped from generation. Values are fully qualified Python type names (‘Module.Class’), but the module can be omitted (‘Class’).
A comma-separated list of keywords for conditional typesystem parsing (see Conditional Processing).
Use the global headers passed on the command line in generated code.
Generator set to be used (e.g. qtdoc).
Skip deprecated functions.
Print a diff of wrapper files.
Dry run, do not generate wrapper files.
Text file containing a description of the binding project. Replaces and overrides command line arguments.
Option to be passed to clang
Options to be passed to clang. When ‘-’ is passed as the first option in the list, none of the options built into shiboken will be added, allowing for a complete replacement.
Emulated compiler type (g++, msvc, clang)
Path to the compiler for determining builtin include paths
Emulated platform (windows, darwin, unix)
Include paths used by the C++ parser.
System include paths used by the C++ parser
Framework include paths used by the C++ parser
C++ Language level (c++11..c++17, default=c++14)
Paths used when searching for type system files.
The directory where the generated files will be written.
File used for copyright headers of generated files.
Show all warnings.
Avoid printing any message.
Set the debug level.
Display this help and exit.
Print information about builtin types
Output version information and exit.
The documentation parser used to interpret the documentation input files (qdoc|doxygen).
Directory used to search code snippets used by the documentation.
Directory with XML files generated by documentation tool.
Directory used to search for extra documentation sections.
Directory where library source code is located.
List of additional XML files to be converted to .rst files (for example, tutorials).
Generate a JSON file containing the class inheritance.
Binding Project File#
Instead of directing the Generator behavior via command line, the binding developer can write a text project file describing the same information, and avoid the hassle of a long stream of command line arguments.
The project file structure#
Here follows a comprehensive example of a generator project file.
[generator-project] generator-set = path/to/generator/CHOICE_GENERATOR header-file = DIR/global.h" /> typesystem-file = DIR/typesystem_for_your_binding.xml output-directory location="OUTPUTDIR" /> include-path = path/to/library/being/wrapped/headers/1 include-path = path/to/library/being/wrapped/headers/2 typesystem-path = path/to/directory/containing/type/system/files/1 typesystem-path = path/to/directory/containing/type/system/files/2 enable-parent-ctor-heuristic