Difference between revisions of "SoC 2011/Generator of libVLC bindings for other languages"
DarthGandalf (talk | contribs) (→More details: Second way is chosen) |
DarthGandalf (talk | contribs) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 9: | Line 9: | ||
Simplified scheme of the whole process: First: libvlc ==c++generator==> libvlc-c++. Then: (libvlc, libvlc-c++) ==swig==> bindings to wanted language (vlc.py, vlc.pm, ...). | Simplified scheme of the whole process: First: libvlc ==c++generator==> libvlc-c++. Then: (libvlc, libvlc-c++) ==swig==> bindings to wanted language (vlc.py, vlc.pm, ...). | ||
| − | C++ wrapper generator probably can be based on existing python bindings generator. So need to understand how does it work, and write a C++ backend. | + | C++ wrapper generator <strike>probably can be based on existing python bindings generator. So need to understand how does it work, and write a C++ backend.</strike> uses doxygen XML output as parser of libvlc headers. |
Second step is to use SWIG on both libvlc and generated libvlc-c++. Using C libvlc is for ability to access raw VLC API if needed. And C++ wrapper is for having classes with autorefcounting inside target language (for languages which support that). SWIG maps destructors to stuff like "def __del__" in python and "sub DESTROY" in perl, so when python/perl/whatever-lang-which-supports-that object, which represents an object of libvlc-c++, loses last reference, the destructor with libvlc_blah_release() is called. | Second step is to use SWIG on both libvlc and generated libvlc-c++. Using C libvlc is for ability to access raw VLC API if needed. And C++ wrapper is for having classes with autorefcounting inside target language (for languages which support that). SWIG maps destructors to stuff like "def __del__" in python and "sub DESTROY" in perl, so when python/perl/whatever-lang-which-supports-that object, which represents an object of libvlc-c++, loses last reference, the destructor with libvlc_blah_release() is called. | ||
| Line 15: | Line 15: | ||
When both steps will be done, need to solve the following problem: python modules usually are named with small letters, perl modules are usually named with camelcase, etc. Different languages have different rules for naming. Raw access functions of course should be named exactly as in C libvlc API, but it would be nice for classes and their methods to follow naming guidelines of the language. | When both steps will be done, need to solve the following problem: python modules usually are named with small letters, perl modules are usually named with camelcase, etc. Different languages have different rules for naming. Raw access functions of course should be named exactly as in C libvlc API, but it would be nice for classes and their methods to follow naming guidelines of the language. | ||
| − | I will use %rename of SWIG. So different vlc.i will just have different %rename's, but will use the same C++ wrapper. Of course, list of %rename's should be generated automatically. Full scheme of the process | + | I will use %rename of SWIG. So different vlc.i will just have different %rename's, but will use the same C++ wrapper. Of course, list of %rename's should be generated automatically. Full scheme of the process was here... But it's no more the case, because architecture was changed. |
== Git repo == | == Git repo == | ||
http://git.videolan.org/?p=vlc/vlc-darthgandalf.git | http://git.videolan.org/?p=vlc/vlc-darthgandalf.git | ||
git://git.videolan.org/vlc/vlc-darthgandalf.git | git://git.videolan.org/vlc/vlc-darthgandalf.git | ||
| − | |||
| − | |||
Latest revision as of 17:46, 25 June 2011
This project is part of Google Summer of Code 2011.
|
Abstract
It would be nice to able to use libvlc from other languages. There're autogenerated bindings for python, and it has nice class interface, but it requires to managing reference count (to call release() in the end) manually, which is not very pythony. The plan is to make an autogenerated C++ wrapper around C libvlc. Reference counting will be automatic via constructors/destructors. Produced wrapper will be used as input for SWIG, which can make bindings for many different languages.
More details
Simplified scheme of the whole process: First: libvlc ==c++generator==> libvlc-c++. Then: (libvlc, libvlc-c++) ==swig==> bindings to wanted language (vlc.py, vlc.pm, ...).
C++ wrapper generator probably can be based on existing python bindings generator. So need to understand how does it work, and write a C++ backend. uses doxygen XML output as parser of libvlc headers.
Second step is to use SWIG on both libvlc and generated libvlc-c++. Using C libvlc is for ability to access raw VLC API if needed. And C++ wrapper is for having classes with autorefcounting inside target language (for languages which support that). SWIG maps destructors to stuff like "def __del__" in python and "sub DESTROY" in perl, so when python/perl/whatever-lang-which-supports-that object, which represents an object of libvlc-c++, loses last reference, the destructor with libvlc_blah_release() is called.
When both steps will be done, need to solve the following problem: python modules usually are named with small letters, perl modules are usually named with camelcase, etc. Different languages have different rules for naming. Raw access functions of course should be named exactly as in C libvlc API, but it would be nice for classes and their methods to follow naming guidelines of the language.
I will use %rename of SWIG. So different vlc.i will just have different %rename's, but will use the same C++ wrapper. Of course, list of %rename's should be generated automatically. Full scheme of the process was here... But it's no more the case, because architecture was changed.
Git repo
http://git.videolan.org/?p=vlc/vlc-darthgandalf.git git://git.videolan.org/vlc/vlc-darthgandalf.git
