On Tue, Mar 24, 2009 at 09:51:20AM +0100, Pritesh Kothari wrote: > > > +/** @file vbox_tmpl.c > > > + * Template File to support multiple versions of VirtualBox > > > + * at runtime :). > > > > Can you explain a little about this idea... & how it works > > First I will give the problem being faced and then how I tried to solve it. > > Problem: I want to support "All" VirtualBox versions after and including > version 2.2 at "Runtime". > > Now since VirtualBox adds Multiple new features for each release, it is but > natural that the C API which I use is volatile across versions and thus I > need a good mechanism to handle multiple versions during runtime. > My solution was something like this: > > I have a single template file called vbox_tmpl.c which is included multiple > times during compilation using some pre-processor magic, for example: I hit that last Friday while starting to review the patch an found that a bit strange. > /* #define NAME(name) vbox22##name */ > vbox_V2_2.c includes vbox_tmpl.c but renames the driver as vbox22Driver, > similarly when i add support for 2.5 i would have > /* #define NAME(name) vbox25##name */ > vbox_V2_5.c which would include vbox_tmpl.c while renaming the driver as > vbox25Driver. This would make sure that it would include the appropriate > header files namely VBoxCAPI_v2_2.h and VBoxCAPI_v2_5.h respectively. > > The Objects which I depend on, basically the IVirtualBox and ISession are > defined in these headers and change for each version depending on the > functionality. These Objects are nothing but structs with function pointers > in them (vtables equivalent of C++) and it would be disaster if i try to > access them if I don't have the right version and thus the crazy stuff above > to circumvent it. > > Hope it is clear now, or else I would try to explain it in more detail again. That's probably worth a README in the vbox/ directory IMHO I guess Dan did a more complete review of the code than mine. One of the issues I had was many pieces of code licenced under the MIT Licence, which is compatible with the LGPL, but I must admit that if you are the authors of that code I would prefer just LGPL. I also saw parts which were MIT but allowed to relicence under LGPL, for the sake of uniformity I would prefer all files provided under LGPLv2 like the other parts of libvirt code. In a sense it's equivalent for you, but for people doing the legal review when trying to embbed libvirt this makes things more complicated. Any chance you could fix all those headers ? thanks, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list