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/