On Fri, Sep 18, 2009 at 2:23 PM, John Meacham
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.
This has the downside that the source code isn't portable to ghc, which a pretty serious drawback. Perhaps one answer is to teach franchise to create a module that reexports stuff from Jhc.Options if that is available, but that seems like a pretty heavy-weight answer that is also extremely limited. What do we do if we want to either link to libcurl or to libwww, whichever is available? How do we specify what needs to be passed to the linker---particularly as the incantation is often something that's hard to guess and stored in some curl-config script? What if certain versions of libcurl are broken and need to be avoided, in which case we should use libwww? These are all real problems that I've run into. Since they were in an executable (darcs), of course, they wouldn't be affected by this particular issue, but we *should* be able to do anything in a library that we can in an executable without jumping through extremely nasty hoops. These issues, of course, are the reason why franchise (and autoconf) exist... And no, I don't have a good answer to any of these questions, except to suggest probably libraries will *need* to support separate compilation for separate targets. Of course, one could already do that by manipulating the JHC_PATH to maintain two sets of library installations, but it'd be nice to have something like that supported natively. For instance, we could have platform-specific subdirectories of directories within the path, so that franchise could specify that a given library (which was built with a preproc configuration for win32) will be put in the win32-specific path. Which reminds me... is there a way to store in a .hl file what libraries it's to be linked with? -- David Roundy