On Thu, Jul 28, 2005 at 12:08:11AM -0400, Dimitry Golubovsky wrote:
1) It didn't declare types for the imported constants, so Haddock wouldn't generate a list over it.
I never tried to make hsffig output documentable: the whole idea is just to write "import FOO_H" in Haskell as one would write "#include
" in C.
Yeah, I understand. I'm just trying to push it a bit ;-) I'd rather be able to directly re-export all that again, saving me having to key it all in manually. Or perhaps declare my own transformer over it (a plugin of sorts, perhaps, so I could work nicely with enums-from-macros in the scenario I've described)
I mentioned this in the Tutorial: hsffig gives the Haskell compiler the same look at information about the library to import as the C compiler would have. It is hard to separate such things: your header file that you include may include ten other headers, five of them related to the library, and the rest from /usr/include
I think, though, that it shouldn't be too hard to filter the data coming back from gcc. For instance, you could just look for stuff after a line ilke: # 1 "/usr/include/ldap.h" and start ignoring when you see a reference to any other file.
3) It tried to list some of the GCC internal conditionals as constants, making the .hsc not compile unless I manually removed some of them.
Can you provide an example of that? With (almost antique) egcs-2.91.66 I never had anything like this. What was in the .hsc file and what was the compilation error?
Without posting too many hundreds of K on a public mailing list, the output of gcc -E -dD /usr/include/ldap.h begins like this: # 1 "/usr/include/ldap.h" # 1 "<built-in>" #define __STDC_HOSTED__ 1 # 1 "<built-in>" #define __GNUC__ 4 # 1 "<built-in>" #define __GNUC_MINOR__ 0 # 1 "<built-in>" #define __GNUC_PATCHLEVEL__ 1 # 1 "<built-in>" #define __SIZE_TYPE__ long unsigned int # 1 "<built-in>" The problem in this particular case was, if memory serves, __STDC_HOSTED__. hsc2hs was unable to evaluate that macro.
I really like the idea, though. Autodetecting these is great, since they could vary somewhat from implementation to implementation.
Exactly: the Haskell compiler gets the same information (e. g. from features.h) as the C compiler got when compiling the library.
Well, that sort of stuff I can already get with hsc2hs (#type and all that). What I was really speaking about is that there is a standard for the LDAP C API. There are many implementations of it, and there are some optional parts of the API as well as some vendor-specific extensions. With a slightly smarter hsffig, it seems it would be possible to provide the exact features in Haskell that are exposed to C for any given implementation, automatically. Really Cool (TM) in my book. Thanks for all your great work. BTW, I have packaged hsffig up for Debian and will be uploading it as soon as possible. (Someone on #haskell had actually pointed me to it, and I had tried it out, before I started this thread.) -- John