This mail is a reply to mails from Charles Lepple and Petr Kubánek dated from july 7 with the same topic.
> From: Charles Lepple > > "One thing with SWIG (and other binding systems) is that it is not > easy to handle errors gracefully. I can't count how many times I got > segmentation violation errors calling well-tested C code from Python > via SWIG. > > I tried using ctypes, which doesn't require any recompilation of the > target library, but it has similar problems. I am surprised. I follow wxWidgets open source project for a while, their python wrapping is done with SWIG and they do not have so many problems with that. Note I have not used SWIG for python (nor python itself) personnally, so perhaps I missed something. > The big advantage to SWIG is supposed to be that you can generate > bindings to many languages once you set things up, but in reality, > each language has its nuances for passing things by > reference, and so > each set of bindings has slightly different semantics. I never say that SWIG will generate all bindings magically without any specific code. The experience I had with SWIG was with Java and Lua on separated projects. In theses cases, once some specific code was set (mostly typemapping), adding methods and objects was not so problematic. > From: Petr Kubánek > > I believe pure Java implementation is doable and will bring more > benefits then hard-to-build generic Swig implementation. > > From: Charles Lepple > > Since our network protocol is so simple, we may want to stick > to that > for access from other languages. (SWIG and ctypes make sense for > libraries like libusb and libhid where you cannot otherwise > access the > device from the target language.)" > I think this still applies. The bulk of the NUT logic is in the > drivers, with a little less in the server and clients. We're not > talking about wrapping the drivers or server, and very little > logic is > actually in the upsclient library. And the code in the upsclient > library (or a C++ library which wraps the upsclient functionality in > object-oriented-ness) can probably be recreated in another language > with less effort than it would take to write the SWIG bindings. I know the upsclient protocol is sipmle and the java wrapping is easily doable, including SSL features. But the target of jNUT is greater than just upsclient and include nut-scanner (dev in progress) and nut-conf (augeas). Actually nut-scanner and nut-conf are libraries or simple executables over these libraries. Calling scanner functions can be done with a wrapper (like SWIG) or with an interprocess method (socket, pipes, dbus, slave process cli ...) talking to a scanner process. > Picking on the Java bindings for a minute, the build procedure for a > JAR file with native code (e.g. x86, not Java bytecode) is more > complex than building a JAR with Pure Java code, and the resulting > library is non-portable. It is true, but the complexity is not so high. About not portable distribution, there are three problems: 1- on a package based platform (like Linuxes), nothing prevent to have plateform specific .jar with dedicated dynamic library, one per distribution per architecture. 2- on other platforms (like Windows), we have 2 solutions: a- distribute dedicated .jar with one plateform-specific dynamic library (probably too many) b- distribute .jar with many dynamic libraries (one for 32 bits, one for 64b ...) and let java choose the good one at run time 3- distribute a .jar with *all* dynamic libraries and let java choosing which one is the correct one. Solutions 2b and 3 can probably be done with a well configured integration and build solution or with cross-compilation. > For Perl and Python, the situation seems even more silly to me - the > current Perl and Python bindings don't require any compilation > (besides the optional bytecode step for Python). I understand the point to not have anything to compile. > I agree that there is value to a consistent API across the various > language bindings, but I don't know that SWIG is the way to go about > doing it. It is not *the*, it is one. > libhid had a pretty basic C API, but due to some arguments being > passed by reference, the resulting SWIG configuration was pretty ugly: > > http://boxster.ghz.cc/projects/libhid/browser/trunk/swig/hid.i > > All in all, maybe it's not a compelling argument against > SWIG, but be > prepared to make major changes to the new C/C++ API to accommodate > various languages and their quirks. I am sure if we use SWIG, we will have some modifications for each target languages. > Also be forewarned that I can be a > merciless style critic of C++ (note that we don't have any in NUT at > the moment)... No problem ;) Best regards Emilien KIA Software Engineer Open Source Team Eaton's Electrical Group PQCO/DPQD -------------------------------------------------------------------------- _______________________________________________ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev