- Shiboken

# Generator Overview

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

Creating new bindings

Each module of the generator system has an specific role.

1. Provide enough data about the classes and functions.

2. Generate valid code, with modifications from typesystems and injected codes.

3. Modify the API to expose the objects in a way that fits you target language best.

4. Insert customizations where handwritten code is needed.

Runtime architecture

The newly created binding will run on top of Shiboken which takes care of interfacing Python and the underlying C++ library.

## Handwritten inputs

Creating new bindings involves creating several pieces of “code”: the header, the typesystem and, in most cases, the injected code.

header A header with `#include` directives 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-header` should 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

#### Usage

    shiboken [options] header-file(s) typesystem-file

#### Options

`--disable-verbose-error-messages`

  Disable verbose error messages. Turn the CPython code hard to debug but saves a few kilobytes in the generated binding.

`--enable-parent-ctor-heuristic`

  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`

  Enable pyside extensions like support for signal/slots. Use this if you are creating a binding based on PySide.

`--enable-return-value-heuristic`

  Enable heuristics to detect parent relationship on return values. For more info, check Return value heuristics.

`--avoid-protected-hack`

  Avoid the use of the ‘#define protected public’ hack.

`--use-isnull-as-nb-bool`

  If a class has an isNull() const method, it will be used to compute the value of boolean casts (see Bool Cast). The legacy option `--use-isnull-as-nb_nonzero` has the same effect, but should not be used any more.

`--lean-headers`

  Forward declare classes in module headers instead of including their class headers where possible.

`--use-operator-bool-as-nb-bool`

  If a class has an operator bool, it will be used to compute the value of boolean casts (see Bool Cast). The legacy option `--use-operator-bool-as-nb_nonzero` has the same effect, but should not be used any more.

`--no-implicit-conversions`

  Do not generate implicit_conversions for function arguments.

`--api-version=<version>`

  Specify the supported api version used to generate the bindings.

`--documentation-only`

  Do not generate any code, just the documentation.

`--drop-type-entries="<TypeEntry0>[;TypeEntry1;...]"`

  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’).

`-keywords=keyword1[,keyword2,...]`

  A comma-separated list of keywords for conditional typesystem parsing (see Conditional Processing).

`--use-global-header`

  Use the global headers passed on the command line in generated code.

`--generation-set`

  Generator set to be used (e.g. qtdoc).

`--skip-deprecated`

  Skip deprecated functions.

`--diff`

  Print a diff of wrapper files.

`--dryrun`

  Dry run, do not generate wrapper files.

`--project-file=<file>`

  Text file containing a description of the binding project. Replaces and overrides command line arguments.

`--clang-option=<option>`

  Option to be passed to clang

`--clang-options=<option1>[,<option2>,...]>`

  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.

`--compiler=<type>`

  Emulated compiler type (g++, msvc, clang)

`--compiler-path=<file>`

  Path to the compiler for determining builtin include paths

`compiler-argument=<argument>`

  Add an argument for the compiler for determining builtin include paths

`--platform=<name>`

  Emulated platform (`android`, `darwin`, `ios`, `linux`, `unix`, `windows`). `CMAKE_SYSTEM_NAME` may be used.

`--platform-version=<version>`

  Platform version

`--arch=<name>`

  Emulated architecture (`x86_64`, `arm64`, `i586`). `CMAKE_SYSTEM_PROCESSOR` may be used.

`-I<path>, --include-paths=<path>[:<path>:...]`

  Include paths used by the C++ parser.

`-isystem<path>, --system-include-paths=<path>[:<path>:...]`

  System include paths used by the C++ parser

`-F<path>, --framework-include-paths=<path>[:<path>:...]`

  Framework include paths used by the C++ parser

`--force-process-system-include-paths=<path>[:<path>:...]`

  Include paths that are considered as system headers by the C++ parser, but should still be processed to extract types

`--language-level=, -std=<level>`

  C++ Language level (c++11..c++17, default=c++14)

`-T<path>, --typesystem-paths=<path>[:<path>:...]`

  Paths used when searching for type system files.

`--output-directory=[dir]`

  The directory where the generated files will be written.

`--license-file=[license-file]`

  File used for copyright headers of generated files.

`--no-suppress-warnings`

  Show all warnings.

`--log-unmatched`

  Prints suppress-warning and rejection elements that were not matched. This is useful for cleaning up old type system files.

`--silent`

  Avoid printing any message.

`--debug-level=[sparse|medium|full]`

  Set the debug level.

`--help`

  Display this help and exit.

`--print-builtin-types`

  Print information about builtin types

`--version`

  Output version information and exit.

#### QtDocGenerator Options

`--doc-parser=<parser>`

  The documentation parser used to interpret the documentation input files (qdoc|doxygen).

`--documentation-code-snippets-dir=<dir>`

  Directory used to search code snippets used by the documentation.

`--documentation-data-dir=<dir>`

  Directory with XML files generated by documentation tool.

`--documentation-extra-sections-dir=<dir>`

  Directory used to search for extra documentation sections.

`--library-source-dir=<dir>`

  Directory where library source code is located.

`--additional-documentation=<file>`

  List of additional XML files to be converted to .rst files (for example, tutorials).

`--inheritance-file=<file>`

  Generate a JSON file containing the class inheritance.

`--disable-inheritance-diagram`

  Disable the generation of the inheritance diagram.

# 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

## Project file tags

The generator project file tags are in direct relation to the command line arguments. All of the current command line options provided by Qt for Python were already seen on the The project file structure, for new command line options provided by additional generator modules (e.g.: qtdoc, Shiboken) could also be used in the generator project file following simple conversion rules.

For tags without options, just write as an empty tag without any attributes. Example:

    --BOOLEAN-ARGUMENT

becomes

    BOOLEAN-ARGUMENT

and

    --VALUE-ARGUMENT=VALUE

becomes

    VALUE-ARGUMENT = VALUE

## Cross Compilation

Shiboken uses libclang to parse the headers of the library to be exposed. When compiling for another platform, the clang parser should ideally use the target of the platform.

Simple bindings may already work when the parser uses the default host platform target. But for bigger projects like Qt, it is important that macros like `QT_POINTER_SIZE` and the platform defines `Q_OS_XXX` are set correctly when parsing files like `qsystemdetection.h` or `qprocessordetection.h`. Some Qt API might be excluded depending on platform and there might be subtle differences depending on word size.

For platform and architecture, the relevant command line options are --platform=<name> and --arch=<name>. They take common platform names and architectures as used in target triplets and can be set to the values of the CMake variables `CMAKE_SYSTEM_NAME` and `CMAKE_SYSTEM_PROCESSOR`, respectively. If the specified platform is different from the host, Shiboken will pass a target triplet based on them to the clang parser.

Optionally, the version of the platform can be specified using the --platform-version=<version>. This is useful when the clang parser defaults to a too-old version.

If this results in a wrong or too generic triplet, it is also possible to directly pass a target triplet in the Clang options specified by --clang-option=<option>. In this case, Shiboken will not pass a target triplet and try to derive the platform/architecture from this triplet.

When using the `Clang` and `GNU` compilers for cross-compiling, the --compiler-path=<file> option should be specified since Shiboken may need to run the compiler to determine system include paths. For most cases, passing the value of the CMake variable `CMAKE_CXX_COMPILER` should work. If the compiler is in the path, it should suffice to pass the compiler type to --compiler=<type> (value of `CMAKE_CXX_COMPILER_ID`).

It is possible (for example, when targeting Android) that `CMAKE_CXX_COMPILER` is a generic compiler that also needs a `--target=` or similar option to locate the correct system include paths. In this case (shiboken failing due to not finding some system headers), the compiler-argument=<argument> can be passed to specify the target.

Typically, a `CMakeLists.txt` files will then look like:

    if (CMAKE_CROSSCOMPILING)
        list(APPEND shiboken_command "--platform=${CMAKE_SYSTEM_NAME}"
                                     "--arch=${CMAKE_SYSTEM_PROCESSOR}"
                                     "--compiler-path=${CMAKE_CXX_COMPILER}")
    endif()

When passing the target triplet:

    if (CMAKE_CROSSCOMPILING)
        list(APPEND shiboken_command "--clang-option=--target=aarch64-none-linux-android"
                                     "--compiler-path=${CMAKE_CXX_COMPILER}")
    endif()

# CMake Usage

The `Shiboken6Tools` CMake package provides an easy way to invoke the Shiboken generator from CMake to create Python bindings for C++ libraries. It is contained in the `shiboken6_generator` wheel. This is achieved using the `shiboken_generator_create_binding` CMake function. This function automates the process of generating binding sources and building the Python extension module.

## Function Signature

    shiboken_generator_create_binding(
        TARGET_NAME <name>
        GENERATED_SOURCES <generated_sources>
        HEADERS <headers>
        TYPESYSTEM_FILE <typesystem_file>
        CPP_LIBRARY <cpp_library>
        [QT_MODULES <qt_modules>]
        [EXTRA_OPTIONS <extra_options>]
        [FORCE_LIMITED_API]
    )

### Arguments

- `TARGET_NAME`: Name of the Python extension module target to create.

- `GENERATED_SOURCES`: List of C++ source files generated by Shiboken.

- `HEADERS`: List of C++ header files to parse.

- `TYPESYSTEM_FILE`: Path to the typesystem XML file.

- `CPP_LIBRARY`: C++ library to link against.

- `QT_MODULES` (optional): List of Qt modules required for the binding.

- `EXTRA_OPTIONS` (optional): Additional command line options for Shiboken.

- `FORCE_LIMITED_API` (optional): Use the Limited API for the generated extension module.

### Usage Example

    shiboken_generator_create_binding(
        TARGET_NAME MyBinding
        GENERATED_SOURCES ${generated_sources}
        HEADERS ${wrapped_header}
        TYPESYSTEM_FILE ${typesystem_file}
        CPP_LIBRARY ${my_library}
        QT_MODULES Core Gui Widgets
        EXTRA_OPTIONS --some-extra-option
        FORCE_LIMITED_API
    )

This macro will generate the binding sources, build the Python module, and link it with the specified libraries and include paths.

For complete usage examples, see:

- SampleBinding Example

- WidgetBinding Example