Difference between revisions of "SoC 2011/Generator of libVLC bindings for other languages"

From VideoLAN Wiki
Jump to navigation Jump to search
(→‎More details: Second way is chosen)
Line 13: Line 13:
 
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.
  
−
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. There're 2 more or less simple ways to achieve this:
+
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.
  
−
One way is to generate different C++ wrappers with different method names for different languages. Of course, using the same generator, with a parameter. Something like "./gencxxwrapper --lang=python". Downside of this is having multiple incompatible C++ wrappers. Some changes (like name of the module itself) are needed for SWIG interface file too, so it will be generated too (probably similar to "Makefile.in -> Makefile"). Though if only module name will need to be changed, it can be specified in argument to swig instead. Full scheme of the process is here: http://alexeysokolov.co.cc/vlc-swig-scheme-1.png
+
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 is here: http://alexeysokolov.co.cc/vlc-swig-scheme-2.png
−
 
 
−
Second way is to 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 is here: http://alexeysokolov.co.cc/vlc-swig-scheme-2.png
 
  
 
== Git repo ==
 
== Git repo ==

Revision as of 12:31, 27 May 2011

This project is part of Google Summer of Code 2011.
Student: Alexey Sokolov
Mentor: Rémi Duraffort

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.

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 is here: vlc-swig-scheme-2.png

Git repo

http://git.videolan.org/?p=vlc/vlc-darthgandalf.git git://git.videolan.org/vlc/vlc-darthgandalf.git

Retrieved from "https://wiki.videolan.org/index.php?title=SoC_2011/Generator_of_libVLC_bindings_for_other_languages&oldid=19267"