=====================================================================
 SIP - A Tool for Generating Python Bindings for C and C++ Libraries
=====================================================================

-----------------
 Reference Guide
-----------------

:Contact:   info@riverbankcomputing.co.uk
:Version:   4.0rc3
:Copyright: Copyright (c) 2004 Riverbank Computing Limited

.. contents:: Table of Contents
.. section-numbering::


Introduction
============

This is the reference guide for SIP 4.0rc3.  SIP is a tool for
automatically generating `Python <http://www.python.org>`__ bindings for C and
C++ libraries.  SIP was originally developed in 1998 for
`PyQt <http://www.riverbankcomputing.co.uk/pyqt/>`__ - the Python bindings for
the Qt GUI toolkit - but is suitable for generating bindings for any C or C++
library.

This version of SIP generates bindings for Python v2.3 or later.  If you want
to generate bindings for earlier versions of Python (going back as far as
Python v1.5) then you need to use `SIP v3.x`_.

There are many other similar tools available.  One of the original such tools
is `SWIG <http://www.swig.org>`__ and, in fact, SIP is so called because it
started out as a small SWIG.  Unlike SWIG, SIP is specifically designed for
bringing together Python and C/C++ and goes to great lengths to make the
integration as tight as possible.

The homepage for SIP is http://www.riverbankcomputing.co.uk/sip/.  Here you
will always find the latest stable version, current development snapshots, and
the latest version of this documentation.


License
-------

SIP is licensed under the same terms as Python itself.  SIP places no
restrictions on the license you may apply to the bindings you create.


Features
--------

SIP, and the bindings it produces, have the following features.

    - bindings are fast to load and minimise memory consumption especially when
      only a small sub-set of a large library is being used

    - automatic conversion between standard Python and C/C++ data types

    - overloading of functions and methods with different argument signatures

    - access to a C++ class's protected methods

    - the ability to define a Python class that is a sub-class of a C++ class,
      including abstract C++ classes

    - support for ordinary C++ functions, class methods, static class methods,
      virtual class methods and abstract class methods

    - the ability to re-implement C++ virtual and abstract methods in Python

    - support for global and class variables

    - support for C++ namespaces

    - support for C++ exceptions and wrapping them as Python exceptions

    - the ability to define mappings between C++ classes and similar Python
      data types that are automatically invoked

    - the ability to automatically exploit any available run time type
      information to ensure that the class of a Python instance object matches
      the class of the corresponding C++ instance

    - full support of the Python interpreter lock, including the ability to
      specify that a C++ function of method may block, therefore allowing the
      lock to be released and other Python threads to run

    - support for the concept of ownership of a C++ instance (i.e. what part of
      the code is responsible for calling the instance's destructor) and how
      the ownership may change during the execution of an application

    - the ability to generate bindings for a C++ class library that itself is
      built on another C++ class library which also has had bindings generated
      so that the different bindings integrate and share code properly

    - a sophisticated versioning system that allows the full lifetime of a C++
      class library, including any platform specific or optional features, to
      be described in a single set of specification files 

    - the ability to include documentation in the specification files which can
      be extracted and subsequently processed by external tools

    - the ability to include copyright notices and licensing information in the
      specification files that is automatically included in all generated
      source code

    - a build system, written in Python, that you can extend to configure,
      compile and install your own bindings without worrying about platform
      specific issues

    - SIP, and the bindings it produces, runs under UNIX, Linux, Windows and
      MacOS/X

SIP also understands the signal/slot type safe callback mechanism implemented
by Qt.  SIP allows new Python signals to be defined, and allows any Python
callable object to be used as a slot.


SIP v3.x
--------

SIP v3.x differs from current versions in the following respects.

    - It uses Python's classic classes to wrap C++ classes (and so generated
      bindings can be built against any version of Python).

    - It does not support the creation of bindings for C libraries.

    - It does not generate bindings that will work on MacOS/X.

    - It is not formally documented.  However, most of this document does
      apply to SIP v3.x - just don't be surprised if you come across something
      that doesn't.

New releases of SIP v3.x may be made in the future, but no significant
development will be done.


SIP Components
--------------

SIP comprises a number of different components.

    - The SIP code generator (``sip`` or ``sip.exe``).  This processes ``.sip``
      specification files and generates C or C++ bindings.  It is covered in
      detail in `Using SIP`_.

    - The SIP header file (``sip.h``).  This contains definitions and data
      structures needed by the generated C and C++ code.

    - The SIP module (``sip.so`` or ``sip.pyd``).  This is a Python extension
      module that is imported automatically by SIP generated bindings and
      provides them with some common utility functions.  See also `Using the
      SIP Module in Applications`_.

    - The SIP build system (``sipconfig.py``).  This is a pure Python module
      that is created when SIP is configured and encapsulates all the necessary
      information about your system including relevant directory names,
      compiler and linker flags, version numbers.  It also includes several
      Python classes and functions which help you write configuration scripts
      for your own bindings.  It is covered in detail in `The SIP Build
      System`_.


Installing SIP
==============

Downloading SIP
---------------

You can get the latest release of the SIP source code from
http://www.riverbankcomputing.co.uk/sip/download.php.

SIP is also included with all of the major Linux distributions.  However, it is
likely to be a version or two out of date.

You may also find more up to date pre-compiled binaries on
`SourceForge <http://sourceforge.net/project/showfiles.php?group_id=61057>`_.


Configuring SIP
---------------

After unpacking the source package (either a ``.tar.gz`` or a ``.zip`` file
depending on your platform) you should then check for any ``README`` files
that relate to your platform.

Next you need to configure SIP by executing the ``configure.py`` script.  For
example::

    python configure.py

This assumes that the Python interpreter is on your path.  Something like the
following may be appropriate on Windows::

    c:\python23\python configure.py

If you have multiple versions of Python installed then make sure you use the
interpreter for which you wish SIP to generate bindings for.

Qt support is automatically enabled if the ``QTDIR`` environment variable is
set.  Use the ``-x`` command line option to disable it.

The full set of command line options is:

-h      Display a help message.
-b dir  The SIP code generator will be installed in the directory ``dir``.
-d dir  The SIP module will be installed in the directory ``dir``.
-e dir  The SIP header file will be installed in the directory ``dir``.
-k      The SIP module will be built as a static library.  This is useful when
        building the SIP module as a Python builtin
-l lib  Explicitly specify the type of Qt library to use, either ``qt``,
        ``qt-mt``, ``qt-mtedu``, ``qtmt``, ``qt-mtedu`` or ``qte``.  This is
        useful if, for example, you have the non-threaded (``qt``) and threaded
        (``qt-mt``) versions of the Qt library installed in the same directory.
-p platform
        Explicitly specify the platform/compiler to be used by the build
        system.  If Qt support is enabled then the platform/compiler used to
        build Qt will be used, otherwise a platform specific default will be
        used.  The ``-h`` option will display all the supported
        platform/compilers and the default.
-u      The SIP module will be built with debugging symbols.
-v dir  By default ``.sip`` files will be installed in the directory ``dir``.
-x      Disable the SIP module's support for Qt.  Support is automatically
        disabled if the ``QTDIR`` environment variables isn't set.

The configure.py script takes many other options that allows the build system
to be finely tuned.  These are of the form ``name=value`` or ``name+=value``.
The ``-h`` option will display each supported ``name``, although not all are
applicable to all platforms.

The ``name=value`` form means that ``value`` will replace the existing value of
``name``.

The ``name+=value`` form means that ``value`` will be appended to the existing
value of ``name``.

For example, the following will reduce the size of module binaries compiled
with GCC::

    python configure.py CXXFLAGS+=-fno-exceptions LFLAGS+=-s

A pure Python module called ``sipconfig.py`` is generated by ``configure.py``.
This defines each ``name`` and its corresponding ``value``.  Looking at it will
give you a good idea of how the build system uses the different options.  It is
covered in detail in `The SIP Build System`_.


Building SIP
------------

The next step is to build SIP by running your platform's ``make`` command.  For
example::

    make

The final step is to install SIP by running the following command::

    make install

(Depending on your system you may require root or administrator privileges.)

This will install the various SIP components.


Using SIP
=========

Bindings are generated by the SIP code generator from a number of specification
files, typically with a ``.sip`` extension.  Specification files look very
similar to C and C++ header files, but often with additional information (in
the form of a *directive* or an *annotation*) and code so that the bindings
generated can be finely tuned.


A Simple C++ Example
--------------------

We start with a simple, but complete, example.  Let's say you have a C++
library that implements a single class called ``Word``.  The class has one
constructor that takes a ``\0`` terminated character string as its single
argument.  The class has one method called ``reverse()`` which takes no
arguments and returns a ``\0`` terminated character string.  The interface to
the class is defined in a header file called ``word.h`` which might look
something like this::

    // Define the interface to the word library.

    class Word {
        const char *the_word;

    public:
        Word(const char *w);

        char *reverse() const;
    };

The corresponding SIP specification file would then look something like this::

    // Define the SIP wrapper to the word library.

    %Module word 0

    class Word {

    %TypeHeaderCode
    #include <word.h>
    %End

    public:
        Word(const char *);

        char *reverse() const;
    };

Obviously a SIP specification file looks very much like a C++ (or C) header
file, but SIP does not include a full C++ parser.  Let's look at the
differences between the two files.

    - The ``%Module`` directive has been added [#]_.  This is used to name the
      Python module that is being created and to give it a *generation* number.
      In this example these are ``word`` and ``0`` respectively.  The
      generation number is effectively the version number of the module.

    - The ``%TypeHeaderCode`` directive has been added.  The text between this
      and the following ``%End`` directive is included literally in the code
      that SIP generates.  Normally it is used, as in this case, to
      ``#include`` the corresponding C++ (or C) header file [#]_.

    - The declaration of the private variable ``this_word`` has been removed.
      SIP does not support access to either private or protected instance
      variables.

    - The name of the argument to the constructor has been removed.  SIP does
      not support named arguments [#]_.

If we want to we can now generate the C++ code in the current directory by
running the following command::

    sip -c . word.sip

However, that still leaves us with the task of compiling the generated code and
linking it against all the necessary libraries.  It's much easier to use the
SIP build system to do the whole thing.

Using the SIP build system is simply a matter of writing a small Python script.
In this simple example we will assume that the ``word`` library we are wrapping
and it's header file are installed in standard system locations and will be
found by the compiler and linker without having to specify any additional
flags.  In a more realistic example your Python script may take command line
options, or search a set of directories to deal with different configurations
and installations.

This is the simplest script (conventionally called ``configure.py``)::

    import os
    import sipconfig

    # The name of the SIP build file generated by SIP and used by the build
    # system.
    build_file = "word.sbf"

    # Get the SIP configuration information.
    config = sipconfig.Configuration()

    # Run SIP to generate the code.
    os.system(" ".join([config.sip_bin, "-c", ".", "-b", build_file, "word.sip"]))
    
    # Create the Makefile.
    makefile = sipconfig.SIPModuleMakefile(config, build_file)

    # Add the library we are wrapping.  The name doesn't include any platform
    # specific prefixes or extensions (e.g. the "lib" prefix on UNIX, or the
    # ".dll" extension on Windows).
    makefile.extra_libs = ["word"]

    # Generate the Makefile itself.
    makefile.generate()

Hopefully this script is self-documenting.  The key parts are the
``Configuration`` and ``SIPModuleMakefile`` classes.  The build system contains
other Makefile classes, for example to build programs or to call other
Makefiles in sub-directories.

After running the script (using the Python interpreter the extension module is
being created for) the generated C++ code and ``Makefile`` will be in the
current directory.

To compile and install the extension module, just run the following
commands [#]_::

    make
    make install

That's all there is to it.

.. [#] All SIP directives start with a ``%`` in the first column.
.. [#] SIP includes many code directives like this.  They differ in where the
       supplied code is placed by SIP in the generated code.
.. [#] It is planned that a future version of SIP will allow arguments to be
       named and that the names will be used as Python keyword arguments.
.. [#] On Windows you might run ``nmake`` instead.


A Simple C Example
------------------

Let's now look at a very similar example of wrapping a C library::

    /* Define the interface to the word library. */

    struct Word {
        const char *the_word;
    };

    struct Word *create_word(const char *w);
    char *reverse(struct Word *word);

The corresponding SIP specification file would then look something like this::

    /* Define the SIP wrapper to the word library. */

    %CModule word 0

    struct Word {

    %TypeHeaderCode
    #include <word.h>
    %End

        const char *the_word;
    };

    struct Word *create_word(const char *);
    char *reverse(struct Word *);

Again, let's look at the differences between the two files.

    - The ``%CModule`` directive has been added.  This has the same syntax as
      the ``%Module`` directive used in the previous example but tells SIP that
      the library being wrapped is implemented in C rather than C++.

    - The ``%TypeHeaderCode`` directive has been added.

    - The names of the arguments to the functions have been removed.

The ``configure.py`` build system script described in the previous example can
be used for this example without change.


A More Complex C++ Example
--------------------------

In this last example we will wrap a C++ library that contains a class that is
derived from a Qt class.  This will demonstrate how SIP allows a class
hierarchy to be split across multiple Python extension modules, and will
introduce SIP's versioning system.

The library contains a single C++ class called ``Hello`` which is derived from
Qt's ``QLabel`` class.  It behaves just like ``QLabel`` except that the text
in the label is hard coded to be ``Hello World``.  To make the example more
interesting we'll also say that the library only supports Qt v3.0 and later,
and also includes a function called ``setDefault()`` that is not implemented
in the Windows version of the library.

The ``hello.h`` header file looks something like this::

    // Define the interface to the hello library.

    #include <qlabel.h>
    #include <qwidget.h>
    #include <qstring.h>

    class Hello : public QLabel {
        // This is needed by the Qt Meta-Object Compiler.
        Q_OBJECT

    public:
        Hello(QWidget *parent, const char *name = 0, WFlags f = 0);

    private:
        // Prevent instances from being copied.
        Hello(const Hello &);
        Hello &operator=(const Hello &);
    };

    #if !defined(Q_OS_WIN)
    void setDefault(const QString &def);
    #endif

The corresponding SIP specification file would then look something like this::

    // Define the SIP wrapper to the hello library.

    %Module hello 0

    %Import qt/qtmod.sip

    %If (Qt_3_0_0 -)

    class Hello : QLabel {

    %TypeHeaderCode
    #include <hello.h>
    %End

    public:
        Hello(QWidget * /TransferThis/, const char * = 0, WFlags = 0);

    private:
        Hello(const Hello &);
    };

    %If (!WS_WIN)
    void setDefault(const QString &);
    %End

    %End

Again we look at the differences, but we'll skip those that we've looked at in
previous examples.

    - The ``%Import`` directive has been added to specify that we are extending
      the class hierarchy defined in the file ``qt/qtmod.sip``.  This file is
      part of PyQt.  The build system will take care of finding the file's
      exact location.

    - The ``%If (Qt_3_0_0 -)`` directive has been added to specify that
      everything [#]_ up to the matching ``%End`` directive only applies to Qt
      v3.0 and later.  ``Qt_3_0_0`` is a *tag* defined in ``qtmod.sip`` [#]_
      using the ``%Timeline`` directive.  ``%Timeline`` is used to define a tag
      for each version of a library's API you are wrapping allowing you to
      maintain all the different versions in a single SIP specification.  The
      build system provides support to ``configure.py`` scripts for working out
      the correct tags to use according to which version of the library is
      actually installed.

    - The ``public`` keyword used in defining the super-classes has been
      removed.  This is not supported by SIP.

    - The ``/TransferThis/`` annotation has been added to the first argument
      of the constructor.  It specifies that if the argument is not 0 (i.e. the
      ``Hello`` instance being constructed has a parent) then ownership of the
      instance is transferred from Python to C++.  It is needed because Qt
      maintains objects (i.e. instances derived from the ``QObject`` class) in
      a hierachy.  When an object is destroyed all of its children are also
      automatically destroyed.  It is important, therefore, that the Python
      garbage collector doesn't also try and destroy them.  This is covered in
      more detail in `Ownership of Objects`_.  SIP provides many other
      annotations that can be applied to arguments, functions and classes.
      Multiple annotations are separated by commas.  Annotations may have
      values.

    - The ``=`` operator has been removed.  This operator is not supported by
      SIP.

    - The ``%If (!WS_WIN)`` directive has been added to specify that everything
      up to the matching ``%End`` directive does not apply to Windows.
      ``WS_WIN`` is another tag defined by PyQt, this time using the
      ``%Platform`` directive.  Tags defined by the ``%Platform`` directive are
      mutually exclusive, i.e. only one may be valid at a time [#]_.

One question you might have at this point is why bother to define the private
copy constructor when it can never be called from Python?  The answer is to
prevent the automatic generation of a public copy constructor.

We now look at the ``configure.py`` script.  This is a little different to the
script in the previous examples for two related reasons.

Firstly, PyQt includes a pure Python module called ``pyqtconfig`` that extends
the SIP build system for modules, like our example, that build on top of PyQt.
It deals with the details of which version of Qt is being used (i.e. it
determines what the correct tags are) and where it is installed.  This is
called a module's configuration module.

Secondly, we generate a configuration module (called ``helloconfig``) for our
own ``hello`` module.  There is no need to do this, but if there is a chance
that somebody else might want to extend your C++ library then it would make
life easier for them.

Now we have two scripts.  First the ``configure.py`` script::

    import os
    import sipconfig
    import pyqtconfig

    # The name of the SIP build file generated by SIP and used by the build
    # system.
    build_file = "hello.sbf"

    # Get the PyQt configuration information.
    config = pyqtconfig.Configuration()

    # Get the extra SIP flags needed by the imported qt module.  Note that
    # this normally only includes those flags (-x and -t) that relate to SIP's
    # versioning system.
    qt_sip_flags = config.pyqt_qt_sip_flags

    # Run SIP to generate the code.  Note that we tell SIP where to find the qt
    # module's specification files using the -I flag.
    os.system(" ".join([config.sip_bin, "-c", ".", "-b", build_file, "-I", config.pyqt_sip_dir, qt_sip_flags, "hello.sip"]))

    # We are going to install the SIP specification file for this module and
    # its configuration module.
    installs = []

    installs.append(["hello.sip", os.path.join(config.default_sip_dir, "hello")])

    installs.append(["helloconfig.py", config.default_mod_dir])

    # Create the Makefile.  The QtModuleMakefile class provided by the
    # pyqtconfig module takes care of all the extra preprocessor, compiler and
    # linker flags needed by the Qt library.
    makefile = pyqtconfig.QtModuleMakefile(
        configuration=config,
        build_file=build_file,
        installs=installs
    )

    # Add the library we are wrapping.  The name doesn't include any platform
    # specific prefixes or extensions (e.g. the "lib" prefix on UNIX, or the
    # ".dll" extension on Windows).
    makefile.extra_libs = ["hello"]

    # Generate the Makefile itself.
    makefile.generate()

    # Now we create the configuration module.  This is done by merging a Python
    # dictionary (whose values are normally determined dynamically) with a
    # (static) template.
    content = {
        # Publish where the SIP specifications for this module will be
        # installed.
        "hello_sip_dir":    config.default_sip_dir,

        # Publish the set of SIP flags needed by this module.  As these are the
        # same flags needed by the qt module we could leave it out, but this
        # allows us to change the flags at a later date without breaking
        # scripts that import the configuration module.
        "hello_sip_flags":  qt_sip_flags
    }

    # This create the helloconfig.py module from the helloconfig.py.in template
    # and the dictionary.
    sipconfig.create_config_module("helloconfig.py", "helloconfig.py.in", content)

Next we have the ``helloconfig.py.in`` template script::

    import pyqtconfig

    # These are installation specific values created when Hello was configured.
    # The following line will be replaced when this template is used to create
    # the final configuration module.
    # @SIP_CONFIGURATION@

    class Configuration(pyqtconfig.Configuration):
        """The class that represents Hello configuration values.
        """
        def __init__(self, sub_cfg=None):
            """Initialise an instance of the class.

            sub_cfg is the list of sub-class configurations.  It should be None
            when called normally.
            """
            # This is all standard code to be copied verbatim except for the
            # name of the module containing the super-class.
            if sub_cfg:
                cfg = sub_cfg
            else:
                cfg = []

            cfg.append(_pkg_config)

            pyqtconfig.Configuration.__init__(self, cfg)

    class HelloModuleMakefile(pyqtconfig.QtModuleMakefile):
        """The Makefile class for modules that %Import hello.
        """
        def finalise(self):
            """Finalise the macros.
            """
            # Make sure our C++ library is linked.
            self.extra_libs.append("hello")

            # Let the super-class do what it needs to.
            pyqtconfig.QtModuleMakefile.finalise(self)

Again, we hope that the scripts are self documenting.

.. [#] Some parts of a SIP specification aren't subject to version control.
.. [#] Actually in ``versions.sip``.  PyQt uses the ``%Include`` directive to
       split the SIP specification for Qt across a large number of separate
       ``.sip`` files.
.. [#] Tags can also be defined by the ``%Feature`` directive.  These tags are
       not mutually exclusive, i.e. any number may be valid at a time.


Ownership of Objects
--------------------

When a C++ instance is wrapped a corresponding Python object is created.  The
Python object behaves as you would expect in regard to garbage collection - it
is garbage collected when its reference count reaches zero.  What then happens
to the corresponding C++ instance?  The obvious answer might be that the
instance's destructor is called.  However the library API may say that when the
instance is passed to a particular function, the library takes ownership of the
instance, i.e. responsibility for calling the instance's destructor is
transferred from the SIP generated module to the library.

The ``/TransferThis/``, ``/Transfer/`` and ``/TransferBack/`` annotations are
used to specify where, and it what direction, transfers of ownership happen.
It is very important that these are specified correctly to avoid crashes (where
both Python and C++ call the destructor) and memory leaks (where neither Python
and C++ call the destructor).


The SIP Reference
=================

The SIP Command Line
--------------------

The syntax of the SIP command line is::

    sip [options] [specification]

``specification`` is the name of the specification file for the module.  If it
is omitted then ``stdin`` is used.

The full set of command line options is:

-h      Display a help message.
-V      Display the SIP version number.
-a file
        The name of the Scintilla API file to generate.  This file contains a
        description of the module API in a form that the Scintilla editor
        component can use for auto-completion and call tips.  By default the
        file is not generated.
-b file
        The name of the build file to generate.  This file contains the
        information about the module needed by the SIP build system to generate
        a platform and compiler specific Makefile for the module.  By default
        the file is not generated.
-c dir  The name of the directory (which must exist) into which all of the
        generated C or C++ code is placed.  By default no code is generated.
-d file
        The name of the documentation file to generate.  Documentation is
        included in specification files using the ``%Doc`` and ``%ExportedDoc``
        directives.  By default the file is not generated.
-e      Support for C++ exceptions is enabled.  The causes all calls to C++
        code to be enclosed in ``try``/``catch`` blocks and C++ exceptions
        converted to Python exceptions.  By default exception support is
        disabled.
-g      The GIL is always released when making calls to C or C++ code and
        reacquired on return.  (This is the SIP v3.x behaviour.)  By default
        the enhanced GIL management functions described in PEP 311 are used so
        that the GIL is released only when necessary.
-I dir  The directory is added to the list of directories searched when looking
        for a specification file given in an ``%Include`` or ``%Import``
        directive.  This option may be given any number of times.
-j number
        The generated code is split into the given number of files.  This make
        it easier to use the parallel build facility of most modern
        implementations of ``make``.  By default 1 file is generated for each C
        structure or C++ class.
-r      Debugging statements that trace the execution of the bindings are
        automatically generated.  By default the statements are not generated.
-s suffix
        The suffix to use for generated C or C++ source files.  By default
        ``.c`` is used for C and ``.cpp`` for C++.
-t tag  The SIP version tag (defined using the ``%Timeline`` directive) or the
        SIP platform tag (defined using the ``%Platforms`` directive) to
        generate code for.  This option may be given any number of times so
        long as the tags do not conflict.
-w      The display of warning messages is enabled.  By default warning
        messages are disabled.
-x feature
        The feature (defined using the ``%Feature`` directive) is disabled.
-z file
        The name of a file containing more command line options.


Using the SIP Module in Applications
====================================

The main purpose of the SIP module is to provide functionality common to all
SIP generated bindings.  It is loaded automatically and most of the time you
will completely ignore it.  However, it does expose some functionality that can
be used by applications.

settracemask(mask)
    If the bindings have been created with SIP's ``-r`` command line option
    then the generated code will produce debugging statements that trace the
    execution of the code.  (It is particularly useful when trying to
    understand the operation of a C++ library's virtual function calls.)

    Debugging statements are generated at the following points:

    - in a C++ virtual function (the mask is ``0x0001``)
    - in a C++ constructor (the mask is ``0x0002``)
    - in a C++ destructor (the mask is ``0x0004``)
    - in a Python type's __init__ method (the mask is ``0x0008``)
    - in a Python type's __del__ method (the mask is ``0x0010``)
    - in a Python type's ordinary method (the mask is ``0x0020``).

    By default the trace mask is zero and all debugging statements are
    disabled.


The SIP Build System
====================

The purpose of the build system is to make it easy for you to write
configuration scripts in Python for your own bindings.  The build system takes
care of the details of particular combinations of platform and compiler.  It
supports over 50 different platform/compiler combinations.

The build system is implemented as a pure Python module called ``sipconfig``
that contains a number of classes and functions.  Using this module you can
write bespoke configuration scripts (e.g. PyQt's ``configure.py``) or use it
with other Python based build systems (e.g.
`Distutils <http://www.python.org/sigs/distutils-sig/distutils.html>`_ and
`SCons <http://www.scons.org>`_).

An important feature of SIP is the ability to generate bindings that are built
on top of existing bindings.  For example, both
`PyKDE <http://www.riverbankcomputing.co.uk/pykde/>`_ and
`PyQwt <http://pyqwt.sourceforge.net/>`_ are built on top of PyQt but all three
packages are maintained by different developers.  To make this easier PyQt
includes its own configuration module, ``pyqtconfig``, that contains additional
classes intended to be used by the configuration scripts of bindings built on
top of PyQt.  The SIP build system includes facilities that do a lot of the
work of creating these additional configuration modules.


``sipconfig`` Functions
-----------------------

create_config_module(module, template, content)
    This creates a configuration module (e.g. ``pyqtconfig``) from a template
    file and a string.

    ``module`` is the name of the configuration module file to create.

    ``template`` is the name of the template file.

    ``content`` is a string which replaces every occurence of the pattern
    ``@SIP_CONFIGURATION@`` in the template file.  The content string is
    usually created from a Python dictionary using
    ``sipconfig.create_content()``.

create_content(dict, dictname="_pkg_config")
    This converts a Python dictionary to a string that can be parsed by the
    Python interpreter and converted back to an equivalent dictionary.  It is
    typically used to generate the content string for
    ``sipconfig.create_config_module()``.

    ``dict`` is the Python dictionary to convert.

    ``dictname`` is the optional name of the dictionary.

    Returns the dictionary as a string.

error(msg)
    This displays an error message on ``stderr`` and calls ``sys.exit()`` with
    a value of 1.

    ``msg`` is the text of the message and should not include any newline
    characters.

format(msg, leftmargin=0, rightmargin=78)
    This formats a message by inserting newline characters at appropriate
    places.

    ``msg`` is the text of the message and should not include any newline
    characters.

    ``leftmargin`` is the optional position of the left margin.

    ``rightmargin`` is the optional position of the right margin.

inform(msg)
    This displays an information message on ``stdout``.

    ``msg`` is the text of the message and should not include any newline
    characters.

read_version(filename, description, numdefine=None, strdefine=None)
    This extracts version information for a package from a file, usually a C or
    C++ header file.  The version information must each be specified as a
    ``#define`` of a numeric (hexadecimal or decimal) value and/or a string
    value.

    ``filename`` is the name of the file to read.

    ``description`` is a descriptive name of the package used in error
    messages.

    ``numdefine`` is the optional name of the ``#define`` of the version as a
    number.  If it is ``None`` then the numeric version is ignored.

    ``strdefine`` is the optional name of the ``#define`` of the version as a
    string.  If it is ``None`` then the string version is ignored.

    Returns a tuple of the numeric and string versions.  ``sipconfig.error()``
    is called if either were required but could not be found.

version_to_sip_tag(version, tags, description)
    This converts a version number to a SIP version tag.  SIP uses the
    ``%Timeline`` directive to define the chronology of the different versions
    of the C/C++ library being wrapped.  Typically it is not necessary to
    define a version tag for every version of the library, but only for those
    versions that affect the library's API as SIP sees it.

    ``version`` is the numeric version number of the C/C++ library being
    wrapped.  If it is negative then the latest version is assumed.  (This is
    typically useful if a snapshot is indicated by a negative version number.)

    ``tags`` is the dictionary of SIP version tags keyed by the corresponding
    C/C++ library version number.  The tag used is the one with the smallest
    key (i.e. earliest version) that is greater than ``version``.

    ``description`` is a descriptive name of the C/C++ library used in error
    messages.

    Returns the SIP version tag.  ``sipconfig.error()`` is called if the C/C++
    library version number did not correspond to a SIP version tag.

version_to_string(v)
    This converts a 3 part version number encoded as a hexadecimal value to a
    string.

    ``v`` is the version number.

    Returns a string.


``sipconfig`` Classes
---------------------

Configuration
    This class encapsulates configuration values that can be accessed as
    instance objects.  A sub-class may provide a dictionary of additional
    configuration values in its constructor the elements of which will have
    precedence over the super-class's values.

    The following configuration values are provided:

        default_bin_dir
            The name of the directory where executables should be installed by
            default.

        default_mod_dir
            The name of the directory where SIP generated modules should be
            installed by default.

        default_sip_dir
            The name of the base directory where the ``.sip`` files for SIP
            generated modules should be installed by default.  A sub-directory
            with the same name as the module should be created and its ``.sip``
            files should be installed in the sub-directory.  The ``.sip``
            files only need to be installed if you might want to build other
            bindings based on them.

        py_inc_dir
            The name of the directory containing the ``Python.h`` header file.

        py_lib_dir
            The name of the directory containing the Python interpreter
            library.

        py_version
            The Python version as a 3 part hexadecimal number (e.g. v2.3.3 is
            represented as ``0x020303``).

        qt_dir
            The name of the Qt base directory.  The value is not present if Qt
            support is disabled.

        qt_edition
            The name of the Qt edition (e.g. enterprise, professional, free).
            The value is not present if Qt support is disabled.

        qt_inc_dir
            The name of the Qt include directory.  The value is not present if
            Qt support is disabled.

        qt_lib
            The name of the Qt library with platform dependent prefixes,
            suffixes and version numbers removed (e.g. qt, qt-mt).  The value
            is not present if Qt support is disabled.

        qt_lib_dir
            The name of the Qt library directory.  The value is not present if
            Qt support is disabled.

        qt_prl_libs
            The additional libraries that need to be linked when linking the
            Qt library.  The value is not present if Qt support is disabled.

        qt_threaded
            A non-zero value if the Qt library includes support for threads.
            The value is not present if Qt support is disabled.

        qt_version
            The Qt version as a 3 part hexadecimal number (e.g. v3.3.0 is
            represented as ``0x030300``).  It is ``0`` if Qt support is
            disabled.

        qt_winconfig
            A string describing the Qt configuration under Windows.  The value
            is not present if Qt support is disabled.

        sip_bin
            The full pathname of the SIP executable.

        sip_inc_dir
            The name of the directory containing the ``sip.h`` header file.

        sip_mod_dir
            The name of the directory containing the SIP module.

        sip_version
            The SIP version as a 3 part hexadecimal number (e.g. v4.0.0 is
            represented as ``0x040000``).

        sip_version_str
            The SIP version as a string.  For development snapshots it will
            start with ``snapshot-``.

    __init__(self, sub_cfg=None)
        Initialise the instance.

        ``sub_cfg`` is an optional list of sub-class configurations.  It should
        only be used by the ``__init__()`` method of a sub-class to append its
        own dictionary of configuration values before passing the list to its
        super-class.

Makefile
    This class encapsulates a Makefile.  It is intended to be sub-classed to
    generate Makefiles for particular purposes.  It handles all platform and
    compiler specific flags, but allows them to be adjusted to suit the
    requirements of a particular module or program.  These are defined using a
    number of macros which can be accessed as instance objects.

    The following instance objects are provided to help in fine tuning the
    generated Makefile:

        chkdir
            A string that will check for the existence of a directory.

        config
            A reference to the ``configuration`` argument that was passed to
            the constructor.

        console
            A reference to the ``console`` argument that was passed to the
            constructor.

        copy
            A string that will copy a file.

        extra_cflags
            A list of additional flags passed to the C compiler.

        extra_cxxflags
            A list of additional flags passed to the C++ compiler.

        extra_defines
            A list of additional macro names passed to the C/C++ preprocessor.

        extra_include_dirs
            A list of additional include directories passed to the C/C++
            preprocessor.

        extra_lflags
            A list of additional flags passed to the linker.

        extra_lib_dirs
            A list of additional library directories passed to the linker.

        extra_libs
            A list of additional libraries passed to the linker.  The names of
            the libraries must be in platform neutral form (i.e. without any
            platform specific prefixes, version numbers or extensions).

        generator
            A string that defines the platform specific style of Makefile.  The
            only supported values are ``UNIX`` and something else that is not
            ``UNIX``.

        mkdir
            A string that will create a directory.

        rm
            A string that will remove a file.

    __init__(self, configuration, console=0, qt=0, opengl=0, python=0, threaded=0, warnings=None, debug=0, dir=None, makefile="Makefile", installs=None)
        Initialise the instance.

        ``configuration`` is the current configuration and is an instance of
        the ``Configuration`` class or a sub-class.

        ``console`` is set if the target is a console (rather than GUI) target.
        This only affects Windows and is ignored on other platforms.

        ``qt`` is set if the target uses Qt.

        ``opengl`` is set if the target uses OpenGL.

        ``python`` is set if the target uses Python.h.

        ``threaded`` is set if the target requires thread support.  It is set
        automatically if the target uses Qt and Qt has thread support enabled.

        ``warnings`` is set if compiler warning messages should be enabled.
        The default of ``None`` means that warnings are enabled for SIP v4.x
        and disabled for SIP v3.x.

        ``debug`` is set if debugging symbols should be generated.

        ``dir`` is the name of the directory where build files are read from
        and Makefiles are written to.  The default of ``None`` means the
        current directory is used.

        ``makefile`` is the name of the generated Makefile.

        ``installs`` is a list of extra install targets.  Each element is a two
        part list, the first of which is the source and the second is the
        destination.  If the source is another list then it is a list of source
        files and the destination is a directory.

    clean_build_file_objects(self, mfile, build)
        This generates the Makefile commands that will remove any files
        generated during the build of the default target.

        ``mfile`` is the Python file object of the Makefile.

        ``build`` is the dictionary created from parsing the build file.

    finalise(self)
        This is called just before the Makefile is generated to ensure that it
        is fully configured.  It must be reimplemented by a sub-class.

    generate(self)
        This generates the Makefile.

    generate_macros_and_rules(self, mfile)
        This is the default implementation of the Makefile macros and rules
        generation.

        ``mfile`` is the Python file object of the Makefile.

    generate_target_clean(self, mfile)
        This is the default implementation of the Makefile clean target
        generation.

        ``mfile`` is the Python file object of the Makefile.

    generate_target_default(self, mfile)
        This is the default implementation of the Makefile default target
        generation.

        ``mfile`` is the Python file object of the Makefile.

    generate_target_install(self, mfile)
        This is the default implementation of the Makefile install target
        generation.

        ``mfile`` is the Python file object of the Makefile.

    install_file(self, mfile, src, dst)
        This generates the Makefile commands to install one or more files to a
        directory.

        ``mfile`` is the Python file object of the Makefile.

        ``src`` is the name of a single file to install or a list of a number
        of files to install.

        ``dst`` is the name of the destination directory.

    optional_list(self, name)
        This returns an optional Makefile macro as a list.

        ``name`` is the name of the macro.

        Returns the macro as a list.

    optional_string(self, name, default="")
        This returns an optional Makefile macro as a string.

        ``name`` is the name of the macro.

        ``default`` is the optional default value of the macro.

        Returns the macro as a string.

    parse_build_file(self, filename)
        This parses a build file (created with the ``-b`` SIP command line
        option).

        ``filename`` is the name of the build file.

        Returns a dictionary corresponding to the parsed build file.

    platform_lib(self, clib)
        This converts a library name to a platform specific form.

        ``clib`` is the name of the library in cannonical form.

        Return the platform specific name.

    ready(self)
        This is called to ensure that the Makefile is fully configured.  It is
        normally called automatically when needed.

    required_string(self, name)
        This returns a required Makefile macro as a string.

        ``name`` is the name of the macro.

        Returns the macro as a string.  An exception is raised if the macro
        does not exist or has an empty value.

ModuleMakefile(Makefile)
    This class encapsulates a Makefile to build a generic Python extension
    module.

    __init__(self, configuration, build_file, install_dir=None, static=0, console=0, opengl=0, threaded=0, warnings=None, debug=0, dir=None, makefile="Makefile", installs=None)
        Initialise the instance.

        ``configuration`` - see ``sipconfig.Makefile.__init__()``.

        ``build_file`` is the name of the build file.  Build files are
        generated using the ``-b`` SIP command line option.

        ``install_dir`` is the name of the directory where the module will be
        optionally installed.

        ``static`` is set if the module should be built as a static library.

        ``console`` - see ``sipconfig.Makefile.__init__()``.

        ``qt`` - see ``sipconfig.Makefile.__init__()``.

        ``opengl`` - see ``sipconfig.Makefile.__init__()``.

        ``threaded`` - see ``sipconfig.Makefile.__init__()``.

        ``warnings`` - see ``sipconfig.Makefile.__init__()``.

        ``debug`` - see ``sipconfig.Makefile.__init__()``.

        ``dir`` - see ``sipconfig.Makefile.__init__()``.

        ``makefile`` - see ``sipconfig.Makefile.__init__()``.

        ``installs`` - see ``sipconfig.Makefile.__init__()``.

    finalise(self)
        This is a reimplementation of ``sipconfig.Makefile.finalise()``.

    generate_macros_and_rules(self, mfile)
        This is a reimplementation of
        ``sipconfig.Makefile.generate_macros_and_rules()``.

    generate_target_clean(self, mfile)
        This is a reimplementation of
        ``sipconfig.Makefile.generate_target_clean()``.

    generate_target_default(self, mfile)
        This is a reimplementation of
        ``sipconfig.Makefile.generate_target_default()``.

    generate_target_install(self, mfile)
        This is a reimplementation of
        ``sipconfig.Makefile.generate_target_install()``.

    module_as_lib(self, mname)
        This returns the name of a SIP v3.x module for when it is used as a
        library to be linked against.  An exception will be raised if it is
        used with SIP v4.x modules.

        ``mname`` is the name of the module.

        Returns the corresponding library name.

ParentMakefile(Makefile)
    This class encapsulates a Makefile that sits above a number of other
    Makefiles in sub-directories.

    __init__(self, configuration, subdirs, dir=None, makefile="Makefile", installs=None)
        Initialise the instance.

        ``configuration`` - see ``sipconfig.Makefile.__init__()``.

        ``subdirs`` is the sequence of sub-directories.

        ``dir`` - see ``sipconfig.Makefile.__init__()``.

        ``makefile`` - see ``sipconfig.Makefile.__init__()``.

        ``installs`` - see ``sipconfig.Makefile.__init__()``.

    generate_macros_and_rules(self, mfile)
        This is a reimplementation of
        ``sipconfig.Makefile.generate_macros_and_rules()``.

    generate_target_clean(self, mfile)
        This is a reimplementation of
        ``sipconfig.Makefile.generate_target_clean()``.

    generate_target_default(self, mfile)
        This is a reimplementation of
        ``sipconfig.Makefile.generate_target_default()``.

    generate_target_install(self, mfile)
        This is a reimplementation of
        ``sipconfig.Makefile.generate_target_install()``.

ProgramMakefile(Makefile)
    This class encapsulates a Makefile to build an executable program.

    __init__(self, configuration, build_file=None, install_dir=None, console=0, qt=0, opengl=0, python=0, threaded=0, warnings=None, debug=0, dir=None, makefile="Makefile", installs=None)
        Initialise the instance.

        ``configuration`` - see ``sipconfig.Makefile.__init__()``.

        ``build_file`` is the name of the optional build file.  Build files are
        generated using the ``-b`` SIP command line option.

        ``install_dir`` is the name of the directory where the executable
        program will be optionally installed.

        ``console`` - see ``sipconfig.Makefile.__init__()``.

        ``qt`` - see ``sipconfig.Makefile.__init__()``.

        ``opengl`` - see ``sipconfig.Makefile.__init__()``.

        ``python`` - see ``sipconfig.Makefile.__init__()``.

        ``threaded`` - see ``sipconfig.Makefile.__init__()``.

        ``warnings`` - see ``sipconfig.Makefile.__init__()``.

        ``debug`` - see ``sipconfig.Makefile.__init__()``.

        ``dir`` - see ``sipconfig.Makefile.__init__()``.

        ``makefile`` - see ``sipconfig.Makefile.__init__()``.

        ``installs`` - see ``sipconfig.Makefile.__init__()``.

    build_command(self, source)
        This creates a single command line that will create an executable
        program from a single source file.

        ``source`` is the name of the source file.

        Returns a tuple of the name of the executable that will be created and
        the command line.

    finalise(self)
        This is a reimplementation of ``sipconfig.Makefile.finalise()``.

    generate_macros_and_rules(self, mfile)
        This is a reimplementation of
        ``sipconfig.Makefile.generate_macros_and_rules()``.

    generate_target_clean(self, mfile)
        This is a reimplementation of
        ``sipconfig.Makefile.generate_target_clean()``.

    generate_target_default(self, mfile)
        This is a reimplementation of
        ``sipconfig.Makefile.generate_target_default()``.

    generate_target_install(self, mfile)
        This is a reimplementation of
        ``sipconfig.Makefile.generate_target_install()``.

SIPModuleMakefile(ModuleMakefile)
    This class encapsulates a Makefile to build a SIP generated Python
    extension module.

    finalise(self)
        This is a reimplementation of ``sipconfig.Makefile.finalise()``.
