I have a large body of C/C++ code at work that I'd like to be able to access from Haskell via FFI. Because the interface to this code is broad, hsffig would seem to be ideal for the task. I've run across one serious hitch, though. The existing #include file graph is complicated and ends up declaring some typedefs multiple times (albeit in consistent ways). While gcc (for example) rejects such practice, the Windows C compiler we're using accepts it. Does anyone know how feasible it would be to get hsffig to accept such practice as well? I've started looking at the hsffig code (and discovered that the C grammar hsffig uses seems to get confused by duplicate typedefs), but thought I'd ask the list in parallel with my further study. Thanks. Dean
heringtonlacey:
I have a large body of C/C++ code at work that I'd like to be able to access from Haskell via FFI. Because the interface to this code is broad, hsffig would seem to be ideal for the task.
I've run across one serious hitch, though. The existing #include file graph is complicated and ends up declaring some typedefs multiple times (albeit in consistent ways). While gcc (for example) rejects such practice, the Windows C compiler we're using accepts it. Does anyone know how feasible it would be to get hsffig to accept such practice as well? I've started looking at the hsffig code (and discovered that the C grammar hsffig uses seems to get confused by duplicate typedefs), but thought I'd ask the list in parallel with my further study.
Have you looked at c2hs? (I'm not sure how familiar people are with hsffig, but Dimitry Golubovsky can probably comment) -- Don
At 9:59 PM -0700 5/13/09, Don Stewart wrote:
heringtonlacey:
I have a large body of C/C++ code at work that I'd like to be able to access from Haskell via FFI. Because the interface to this code is broad, hsffig would seem to be ideal for the task.
I've run across one serious hitch, though. The existing #include file graph is complicated and ends up declaring some typedefs multiple times (albeit in consistent ways). While gcc (for example) rejects such practice, the Windows C compiler we're using accepts it. Does anyone know how feasible it would be to get hsffig to accept such practice as well? I've started looking at the hsffig code (and discovered that the C grammar hsffig uses seems to get confused by duplicate typedefs), but thought I'd ask the list in parallel with my further study.
Have you looked at c2hs? (I'm not sure how familiar people are with hsffig, but Dimitry Golubovsky can probably comment)
-- Don
Yes, I started this journey with c2hs. Then I moved to hsc2hs, which appeared to be a "standardized" version of the same approach. But my interface consists of hundreds (maybe thousands) of #defines, structs, typedefs, etc., so I quickly tired of the boilerplate wrapping code, modest as it is. Dean
heringtonlacey:
At 9:59 PM -0700 5/13/09, Don Stewart wrote:
heringtonlacey:
I have a large body of C/C++ code at work that I'd like to be able to access from Haskell via FFI. Because the interface to this code is broad, hsffig would seem to be ideal for the task.
I've run across one serious hitch, though. The existing #include file graph is complicated and ends up declaring some typedefs multiple times (albeit in consistent ways). While gcc (for example) rejects such practice, the Windows C compiler we're using accepts it. Does anyone know how feasible it would be to get hsffig to accept such practice as well? I've started looking at the hsffig code (and discovered that the C grammar hsffig uses seems to get confused by duplicate typedefs), but thought I'd ask the list in parallel with my further study.
Have you looked at c2hs? (I'm not sure how familiar people are with hsffig, but Dimitry Golubovsky can probably comment)
-- Don
Yes, I started this journey with c2hs. Then I moved to hsc2hs, which appeared to be a "standardized" version of the same approach. But my interface consists of hundreds (maybe thousands) of #defines, structs, typedefs, etc., so I quickly tired of the boilerplate wrapping code, modest as it is.
hsc2hs is much simpler than c2hs. In particular, it processes the header files (unlike hsc2hs) to work out the appropriate type. I'd be interesting to hear how you go with hsffig (and you should contact the author!). -- Don
At 10:12 PM -0700 5/13/09, Don Stewart wrote:
heringtonlacey:
At 9:59 PM -0700 5/13/09, Don Stewart wrote:
heringtonlacey:
I have a large body of C/C++ code at work that I'd like to be able to access from Haskell via FFI. Because the interface to this code is broad, hsffig would seem to be ideal for the task.
I've run across one serious hitch, though. The existing #include file graph is complicated and ends up declaring some typedefs multiple times (albeit in consistent ways). While gcc (for example) rejects such practice, the Windows C compiler we're using accepts it. Does anyone know how feasible it would be to get hsffig to accept such practice as well? I've started looking at the hsffig code (and discovered that the C grammar hsffig uses seems to get confused by duplicate typedefs), but thought I'd ask the list in parallel with my further study.
Have you looked at c2hs? (I'm not sure how familiar people are with hsffig, but Dimitry Golubovsky can probably comment)
-- Don
Yes, I started this journey with c2hs. Then I moved to hsc2hs, which appeared to be a "standardized" version of the same approach. But my interface consists of hundreds (maybe thousands) of #defines, structs, typedefs, etc., so I quickly tired of the boilerplate wrapping code, modest as it is.
hsc2hs is much simpler than c2hs. In particular, it processes the header files (unlike hsc2hs) to work out the appropriate type.
Yes, but both c2hs and hsc2hs require the (normally modest but for this situation burdensome) wrapping code. hsffig would produce a (huge) Haskell module with all the interface components available. (In fact I have some concern about the module being too big.) A big win for me would be the ability to write concise code to drill down through nested C structures returned by the foreign functions (without having to process each such module through c2hs or hsc2hs).
I'd be interesting to hear how you go with hsffig (and you should contact the author!).
I'll let the list know how it goes, and will certainly be in touch with Dimitry. Thanks. Dean
participants (2)
-
Dean Herington -
Don Stewart