cvs commit: fptools/libraries/base/Foreign/C Error.hs fptools/libraries/base/System/Posix Internals.hs fptools/libraries/network /Network Socket.hsc

[Alastair Reid]

[copied to cvs-hugs]

ross 2003/04/11 16:39:44 PDT 
> Modified files:
> libraries/base/Foreign/C Error.hs libraries/base/System/Posix
> Internals.hs libraries/network/Network Socket.hsc 
>
> Log:
> Hugs only: add a CBITS "pragma" to tell the Hugs conversion script
> which files from <package>/cbits should be linked with the module by
> ffihugs, e.g. {-# CBITS HsNet.c initWinSock.c ancilData.c #-}

This is great stuff you're doing to make packages available in Hugs.

Is this the best way to handle cbits though?

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.

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.)

--
Alastair Reid