PySide Binding Generation Tutorial: Module 2 Binding libfoo using Shiboken: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
No edit summary
Line 1: Line 1:
'''English''' [http://qt-devnet.developpez.com/tutoriels/python/pyside/binding-shiboken/#LIV French] ''[qt-devnet.developpez.com]''
[[Category:LanguageBindings::PySide::Shiboken::PySide Binding Generation Tutorial]]<br />[toc align_right=&quot;yes&amp;quot; depth=&quot;3&amp;quot;]


* '''Note:''' this article is a member of the multipart [http://developer.qt.nokia.com/wiki/Category:LanguageBindings::PySide::Shiboken::PySide_Binding_Generation_Tutorial PySide Binding Generation Tutorial] ''[developer.qt.nokia.com]''
'''English''' &quot;French&amp;quot;:http://qt-devnet.developpez.com/tutoriels/python/pyside/binding-shiboken/#LIV


=Binding libfoo using Shiboken=
* '''Note:''' this article is a member of the multipart &quot;PySide Binding Generation Tutorial&amp;quot;:http://developer.qt.nokia.com/wiki/Category:LanguageBindings::PySide::Shiboken::PySide_Binding_Generation_Tutorial
 
= Binding libfoo using Shiboken =


In order to create bindings for a library based on Qt, a number of components must be available on the system:
In order to create bindings for a library based on Qt, a number of components must be available on the system:


* Qt library (with headers and '''pkg-config''' <code>.pc</code> files for development – the '''-dev''' packages in a Debian-like distribution).
* Qt library (with headers and '''pkg-config''' &lt;code&amp;gt;.pc&amp;lt;/code&amp;gt; files for development – the '''-dev''' packages in a Debian-like distribution).
* Qt Python bindings made with Shiboken, i.e. PySide.
* Qt Python bindings made with Shiboken, i.e. PySide.
* Type systems for the Qt Python bindings.
* Type systems for the Qt Python bindings.
Line 15: Line 17:


* Type system file describing the way the binding must be done.
* Type system file describing the way the binding must be done.
* <code>global.h</code> including all the '''libfoo''' headers and defining required macros.
* &lt;code&amp;gt;global.h&amp;lt;/code&amp;gt; including all the '''libfoo''' headers and defining required macros.
* A build system to direct the process of generating, compiling and linking the binding.
* A build system to direct the process of generating, compiling and linking the binding.


==libfoo bindings with Makefile==
== libfoo bindings with Makefile ==


The directory structure and contents for the Makefile binding project could be something like the tree shown below:
The directory structure and contents for the Makefile binding project could be something like the tree shown below:


The <code>foobinding-makefile</code> directory should contain the <code>global.h</code>, which is a central point to include all the '''libfoo''' headers (ok, it’s just one header, but a real life library will certainly have more headers), it could also contain '''#define''' clauses that will influence the parsing of the headers by the generator. Nevermind the <code>pyside_global.h</code> file, it’ll be explained later. The <code>typesystem_foo.xml</code> describes how to export the wrapped C++ library to Python as explained in [https://developer.qt.nokia.com/wiki/PySide_Binding_Generation_Tutorial:_Module_3_Creating_Type_System_Description Module 3] ''[developer.qt.nokia.com]''.
<code><br />foobinding-makefile/<br />|— foo/<br />|— global.h<br />|— Makefile<br />|— pyside_global.h<br />`— typesystem_foo.xml<br /></code>
 
The <code>foo</code> directory is the place where the generated sources will be placed. It starts empty and its name will be the same as the package name found in the type system file:


If there is any need for handwritten source code longer than a couple of lines, making it inconvenient to put them in the type system xml file, the sources could be orderly placed in a <code>glue</code> directory. For the '''foo''' bindings no custom code will be needed.
The &lt;code&amp;gt;foobinding-makefile&amp;lt;/code&amp;gt; directory should contain the &lt;code&amp;gt;global.h&amp;lt;/code&amp;gt;, which is a central point to include all the '''libfoo''' headers (ok, it's just one header, but a real life library will certainly have more headers), it could also contain '''#define''' clauses that will influence the parsing of the headers by the generator. Nevermind the &lt;code&amp;gt;pyside_global.h&amp;lt;/code&amp;gt; file, it'll be explained later. The &lt;code&amp;gt;typesystem_foo.xml&amp;lt;/code&amp;gt; describes how to export the wrapped C++ library to Python as explained in &quot;Module 3&amp;quot;:https://developer.qt.nokia.com/wiki/PySide_Binding_Generation_Tutorial:_Module_3_Creating_Type_System_Description.


When writing the type system file (more on this later) there is no need to refer to the other required type system 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 '''<span class="caps">TYPESYSTEMPATH</span>'''.
The &lt;code&amp;gt;foo&amp;lt;/code&amp;gt; directory is the place where the generated sources will be placed. It starts empty and its name will be the same as the package name found in the type system file:


==libfoo bindings with CMake==
<code><br />&lt;typesystem package=&quot;foo&amp;quot;&gt;<br /></code>


The directory structure for the CMake based '''libfoo''' bindings is a bit more elaborate:
If there is any need for handwritten source code longer than a couple of lines, making it inconvenient to put them in the type system xml file, the sources could be orderly placed in a &lt;code&amp;gt;glue&amp;lt;/code&amp;gt; directory. For the '''foo''' bindings no custom code will be needed.


This structure follows the one used in the '''PySide''' bindings: a root directory, one directory for the binding information (essentially the same as the Makefile example), and a <code>tests<code> directory which is a Good Thing™ to have.</code></code>
When writing the type system file &amp;#40;more on this later&amp;amp;#41; there is no need to refer to the other required type system 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'''.


===Categories:===
== libfoo bindings with CMake ==


* [[:Category:LanguageBindings|LanguageBindings]]
The directory structure for the CMake based '''libfoo''' bindings is a bit more elaborate:
** [[:Category:LanguageBindings::PySide|PySide]]
* [[:Category:LanguageBindings::PySide::Shiboken|Shiboken]]


* [[:Category:LanguageBindings::PySide::Shiboken::PySide Binding Generation Tutorial|PySide_Binding_Generation_Tutorial]]
<code><br />foobinding-cmake/<br />|— CMakeLists.txt<br />|— foo/<br />| |— CMakeLists.txt<br />| |— global.h<br />| |— pyside_global.h<br />| `— typesystem_foo.xml<br />`— tests/<br /> `— CMakeLists.txt<br /> `— math_test.py<br /></code>

Revision as of 09:35, 24 February 2015


[toc align_right="yes&quot; depth="3&quot;]

English "French&quot;:http://qt-devnet.developpez.com/tutoriels/python/pyside/binding-shiboken/#LIV

Binding libfoo using Shiboken

In order to create bindings for a library based on Qt, a number of components must be available on the system:

  • Qt library (with headers and pkg-config <code&gt;.pc&lt;/code&gt; files for development – the -dev packages in a Debian-like distribution).
  • Qt Python bindings made with Shiboken, i.e. PySide.
  • Type systems for the Qt Python bindings.
  • Headers for the library to be wrapped.

With the items listed above the developer must collect information used by the generator to create the binding source code:

  • Type system file describing the way the binding must be done.
  • <code&gt;global.h&lt;/code&gt; including all the libfoo headers and defining required macros.
  • A build system to direct the process of generating, compiling and linking the binding.

libfoo bindings with Makefile

The directory structure and contents for the Makefile binding project could be something like the tree shown below:

<br />foobinding-makefile/<br />| foo/<br />| global.h<br />| Makefile<br />| pyside_global.h<br />`— typesystem_foo.xml<br />

The <code&gt;foobinding-makefile&lt;/code&gt; directory should contain the <code&gt;global.h&lt;/code&gt;, which is a central point to include all the libfoo headers (ok, it's just one header, but a real life library will certainly have more headers), it could also contain #define clauses that will influence the parsing of the headers by the generator. Nevermind the <code&gt;pyside_global.h&lt;/code&gt; file, it'll be explained later. The <code&gt;typesystem_foo.xml&lt;/code&gt; describes how to export the wrapped C++ library to Python as explained in "Module 3&quot;:https://developer.qt.nokia.com/wiki/PySide_Binding_Generation_Tutorial:_Module_3_Creating_Type_System_Description.

The <code&gt;foo&lt;/code&gt; directory is the place where the generated sources will be placed. It starts empty and its name will be the same as the package name found in the type system file:

<br />&lt;typesystem package=&quot;foo&amp;quot;&gt;<br />

If there is any need for handwritten source code longer than a couple of lines, making it inconvenient to put them in the type system xml file, the sources could be orderly placed in a <code&gt;glue&lt;/code&gt; directory. For the foo bindings no custom code will be needed.

When writing the type system file &#40;more on this later&amp;#41; there is no need to refer to the other required type system 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.

libfoo bindings with CMake

The directory structure for the CMake based libfoo bindings is a bit more elaborate:

<br />foobinding-cmake/<br />| CMakeLists.txt<br />| foo/<br />| | CMakeLists.txt<br />| | global.h<br />| | pyside_global.h<br />| `— typesystem_foo.xml<br />`— tests/<br /> `— CMakeLists.txt<br /> `— math_test.py<br />