On Wed, 2008-03-05 at 17:37 -0800, John Meacham wrote:
On Thu, Mar 06, 2008 at 12:23:35AM +0000, Duncan Coutts wrote:
Which is really annoying :-) I'd like greater control over it, in particular a way to limit headers to package scope so that dependent code does not need the headers.
Ideally there would be no need for headers at all. Everything needed is inherently in the foreign declaration. If anything, the headers should just be used as a sanity check, not actually to affect the generated code. It would be nice if ghc just stopped relying on them and ignored them altogether.
We're going to have to figure out what to do with crazy header files that use lots of macros. For example the mage-1.1.0 package does not compile without -fvia-C. This is because of the curses.h interface. For example: foreign import ccall unsafe "curses.h & ACS_UARROW" acs_uarrow :: Ptr ChType And what is "ACS_UARROW"? We might hope it's a pointer with a corresponding linker symbol. Sadly not: #define ACS_UARROW NCURSES_ACS('-') /* arrow pointing up */ where: #define NCURSES_ACS(c) (acs_map[NCURSES_CAST(unsigned char,c)]) extern NCURSES_EXPORT_VAR(chtype) acs_map[]; Yay, it's an index into an array. So that obviously does not work. If we compile without going via C we get a linker error because there is no ACS_UARROW linker symbol. If we compile via C then through a bit of luck it seems to compile. There are rather too many of these C libs that define their public interfaces as macros. I had to adjust the zlib binding the other day to allow it to compile without -fvia-C. It now implements a couple macros in the Haskell code. I hope zlib don't change their macro in the next version. Duncan