scope of header files

[Duncan Coutts]

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