[jhc] including C source files?

[John Meacham]

On Fri, Sep 18, 2009 at 10:27:12AM -0400, David Roundy wrote:
> Hmmm.  That'll work fine for executables (although it still needs to
> be implemented), but doesn't seem like it'll work at all for
> jhc-written haskell libraries, at least, it won't work if they're to
> be cross-compile-friendly.  For that, it'd be better to include the C
> code itself in the .hl file, so that it can be built alongside the
> haskell code with whatever compiler is being used...

Yeah. I don't have a good solution for this right now. generally I
assume that a .hl file will link against an existing C library, but
sometimes some stub C is needed. The long term goal I think would be for
jhc to accept hsc files directly (with the #inline pragmas for embedded
C) then include the C in a special section of the .hl file like you say.

> Of course, I'm not sure how cross-compile-friendly jhc libraries can
> be built, unless they themselves need to do nothing platform-specific.
> It seems like a tough problem, but one that would be worth solving.
> e.g. preprocessing is done at compile time, so we can't use
> preprocessor directives to build code based on the target platform.
> Is there a plan for handling this sort of case? e.g. a very simple
> library that reexports some platform-specific API in a cross-platform
> way, e.g. handling emailing via MAPI on win32, but via sendmail on
> unixy systems.

Libraries are fairly cross-compiler friendly by default, it is okay in
jhc to have FFI calls in the source that don't end up in the compiled
code, for instance, the proper way to do emailing via different APIs is
something like


> sendEmail = If Jhc.Options.isWindows
>       then mapiSendEmail 
>       else sendmailSendEmail 


now, once the target arch is determined (generally when doing the whole
program analysis, but it can even be defered to the C code) then
isWindows is resolved and the correct mailing routine is used. 

So, in general, to write cross platform libraries.

use the tests in Jhc.Options, _not_ the preprocessor. if you need to
know the word size or things like that, use storable. as in

> ptrSize = Foreign.Storable.sizeOf (undefined::IntPtr)

and things will just work. 

Now, I believe this should work for many cases that required
preprocessor support before, I do however have fields in the library
file for making them arch specific but they currently arn't used.

        John



-- 
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/