Announce: Yet Another Tool to Generate FFI Bindings: hsffig

I am pleased to announce the very first alpha release of the (yet another) FFI binding autogeneration tool. Some time ago, I asked the list subscribers about available bindings to Berkeley DB. Several people kindly shared their code with me. One thing I noticed in all bindings: they required manually-written wrappers to accomodate for Berkeley DB indirect style of calling functions. Considering large number of such functions in BDB, I attempted to write a tool which would automatically parse the BDB include file, and extract function prototypes to generate FFI declarations. Soon it became clear that an almost full C syntax parser would be necessary. Finally it resulted in what I am presenting to the Haskell community with hope that this utility will be useful to many developers. Of course there are many omissions and shortcuts, but before I move forward, I would like to get some feedback from potential users of this tool. There is no detailed documentation. I have written a brief README file. More detailed documentation will follow. I haven't created a homepage for this project yet: the only way to get it so far is the darcs repo: darcs get http://www.golubovsky.org/repos/hsffig Files in the repository may be browsed at: http://www.golubovsky.org/repos/hsffig/ I will appreciate any feedback. Dimitry Golubovsky Middletown, CT

On Sat, 2005-06-25 at 03:39 -0400, Dimitry Golubovsky wrote:
I am pleased to announce the very first alpha release of the (yet another) FFI binding autogeneration tool.
[...]
http://www.golubovsky.org/repos/hsffig/
I will appreciate any feedback.
You may be interested to know that there is a new C lexer and parser for c2hs (which is another excelent Haskell FFI preprocessor). The new lexer and parser were written to improve the parsing performance on large C headder files. It uses Alex and Happy and parses about 1Mb of C headers in two seconds (on a fast machine) using reasonably little heap space. If a GPL license is ok for you, you might be able to borrow/share the implementation. Duncan
participants (2)
-
Dimitry Golubovsky
-
Duncan Coutts