[jhc] including C source files?

[David Roundy]

On Fri, Sep 18, 2009 at 2:23 PM, John Meacham <john at repetae.net> wrote:
>> 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