Just $0.02 to add to Dave's comments.
I've been using SWIG on and off for 10+ years. Even wrote a fairly popular
article about it (http://drdobbs.com/cpp/184403568). My current project
uses a single SWIG file to wrap 6 languages. I added Ruby bindings in less
than a day, and that was mostly understanding how to link the module.
In our case, we specifically tailored our classes and headers to be
SWIG-wrapable from the start. This proved to be a tremendous productivity
boost, as our SWIG file is mainly %include <foo.h> statements, that wrap
SWIG generally gives "good enough" bindings. Custom bindings for a project
like Blender need to go way beyond what SWIG might offer and so it makes
sense to hand code. My experience has been that hand-coding an interface
starts shiny and new, but slowly becomes a drudgery to maintain.
+1 for not using the advanced customization features. They can be tricky
and not always worth the effort.
On 4/14/11 9:13 PM, "David Beazley" <dave@...> wrote:
> As the original creator of Swig, my response to this criticism is simply "it
> depends." How big is this third party library? What is the complexity of
> its API? Is the API going to change a lot? How much time do you want to
> spend messing around with it?
> Historically, Swig was created primarily for use by applications programmers
> working with frequently changing C/C++ code (for instance, in scientific
> computing where users were constantly making code changes). By automating
> the wrapping process, you didn't really have to worry about changes to the
> underlying code base--such changes would simply show up in the resulting
> Python interface. Similarly, if someone had a huge library that they
> wanted to wrap, Swig could automate large parts of the process.
> I think your developer is basically right that in that even if you use Swig,
> someone is still going to have to maintain the interface files. Moreover,
> there are special cases that you will have to handle. However, there are
> also a lot of very complicated things that Swig *DOES* handle correctly and
> which are a real pain the ass to write by hand. For instance, if you're
> wrapping some library that has 50 C++ class definitions, only a masochist is
> going to sit down and define 50 Python types directly using the Python C API.
> Swig also has a lot of built-in support for proper type checking, casting of
> pointers, overloaded functions, etc. not to mention a lot of portability
> features related to different operating systems, compiler flags, etc.
> Also, keep in mind that Swig and hand-written wrappers are not mutually
> exclusive. If you know what you're doing, Swig can be used to make a Python
> interface very rapidly--maybe to put a prototype together. Over time, you can
> always moved code into hand-written wrappers if you want.
> Regarding the "complexity" of Swig, it really depends on how you use it. I
> for one, hardly ever used the more advanced customization features of Swig and
> rarely had problems. On the other hand, there are some developers who feel
> some need to go completely over the top with typemaps and other insanity.
> Frankly, I think a lot of that is just crazy, but that's just me. I think a
> common confusion for newcomers is that they think they *have* to do that stuff
> to use Swig--which is simply wrong.
> As for the "dream of write-once, bind everywhere without any additional
> effort" comment, do real Swig developers even do that? Although it might be
> theoretically possible, I think most users probably just stick with their one
> favorite language whatever it happens to be. The main benefit of multiple
> language modules, really, is that you can reuse a lot of Swig's basic C
> parsing functionality to make a wrapper generator for some new language
> without having to code the whole thing from scratch. If you're careful about
> how you do things, you can make modules that work in multiple languages, but
> you have to know what you're doing.
> Anyways, my inclination would be to just let the guy do his hand-written
> wrappers. If it takes less than a week, it's probably no big deal. On the
> other hand, if he's wasting a ton of time for months on end, tell him to just
> use Swig and get on it with already.
> On Apr 14, 2011, at 8:24 PM, Nathan Hand wrote:
>> Our organisation has a developer who is opposed to using SWIG for binding a
>> third-party library. He¹s keen to develop bindings for his pet language
>> (python) but that would have the unintended consequence of cementing python
>> for all in-house development. His comments are below:
>> SWIG is just another way to write bindings it¹s not magic and someone still
>> has to write and maintain the SWIG definitions that can be used to generate
>> bindings for various other languages. If it were that easy, and worked so
>> well, everyone would use it, but in reality just about no one does because
>> the price you pay for generality is (high levels) of complexity.
>> Like many ³generic² solutions SWIG fails to handle lots of special cases, and
>> you have to end up coding lots of language-specific exceptions anyway,
>> especially as you start dealing with complex data structures that need to be
>> marshalled from C land to various representations in high-level languages. So
>> you end up with the SWIG-Python bindings, the SWIG-Perl bindings etc,
>> defeating the purpose of a generic binding definition in the first place
>> As a result most people avoid the huge overhead and complexity of SWIG and
>> just write language bindings directly it turns out that once you have
>> written bindings for a given language, it is much easier to just translate
>> the code into bindings for a different language than it is to write a generic
>> mapping using tools like SWIG that usually fail to deliver the dream of
>> write-once, bind-everywhere without any additional effort.
>> I¹m not experienced enough to argue against the developer, although my gut
>> tells me he¹s wrong and writing bindings for a single language is ultimately
>> a waste of time. Can the SWIG developers here give me some counter-arguments?
>> Benefiting from Server Virtualization: Beyond Initial Workload
>> Consolidation -- Increasing the use of server virtualization is a top
>> priority.Virtualization can reduce costs, simplify management, and improve
>> application availability and disaster protection. Learn more about boosting
>> the value of server virtualization.
>> Swig-user mailing list
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> Swig-user mailing list
Daniel Blezek, PhD
Medical Imaging Informatics Innovation Center
P 127 or (77) 8 8886
T 507 538 8886
200 First St. S.W.
Rochester, MN 55905
"It is more complicated than you think." -- RFC 1925