I've never been overly keen on GHC's use of pragmas containing extra command line arguments for GHC because they seem to be about just one way of compiling the code (that is, they are compiler specific and, sometimes, backend specific) so they don't seem to really belong in source code.

We primarily use OPTIONS pragmas to specify options that describe the nature of the source code in the module. For example, -fglasgow-exts says that this source file contains code written in Haskell + GHC extensions. The source code is exactly the right place for this option to go. Admittedly, OPTIONS should be called GHC_OPTIONS. Even better, we should use a compiler-independent way to specify the language flavour in the source file, eg. {-# LANGUAGE ffi, ghc #-}, which would also give other compilers a chance to complain if they don't support that particular language variant. OPTIONS is also used to specify #includes for the C back-end. The source code is the right place for these too, but the use of OPTIONS is a little clunky. We *could* add these to the FFI declarations instead, but (a) it's verbose (you have to add the #include to every foreign import that needs it) and (b) GHC doesn't support it very well.

The CBITS pragma doesn't have the more obvious problems of the GHC mechanism (e.g., the contents of the pragma are unlikely to have to change from one version of Hugs to another) but it feels similar enough to make me a little uneasy.

So I guess I'm asking:

1) Are there other design options?

2) Can the problem of associating C files with Haskell ffi files be solved in a way that all compilers (and associated tools, makefiles, etc.) can support and exploit?

(e.g., other compilers support the CBITS pragma, or an ffi extension, or a package configuration file extension, or a text file which can be read both by GHC makefiles and by your package conversion script, etc.)

I have a feeling that there are enough differences between the way Hugs works and the way GHC works to make trying to unify these things awkward. I suppose you could add something to the package spec which lists C files and the libraries they should be linked into - but unless you can put *all* the information into the package spec (i.e. leaving a completely generic Makefile / conversion script etc.) it doesn't really buy you very much. This brings us back to having a decent library-building infrastructure. My vote would be to do all this in the infrastructure, centralising the knowledge about the differences between compilers. Cheers, Simon