[jhc] including C source files?

[John Meacham]

On Fri, Sep 18, 2009 at 05:35:59PM -0400, David Roundy wrote:
> 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.

Yeah. I figure a file with things like 

#if defined(__GHC__) && defined(__WIN32__)
isWindows = True
#else
isWindows = False
#endif

could be included for other compilers. Franchise shouldn't have to do
anything in particular other than include that module (which will just
re-export Jhc.Options on jhc).

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

Yes. I didn't intend '.hl' files to be a one size fits all solution to
haskell library distribution in jhc. Then I would be commiting the
cardinal sin that cabal did, assuming a one-size fits all solution even
exists for this problem :). 

For many packages, I imagine they will be distributed exactly as they
are for ghc, as source code bundled with an appropriate build script
(autoconf/franchise/cabal/aegis/make/rake/bake/etc..). The user will
compile and install on their local system so having the hl file be
system specific isn't an issue. Of course, they may or may not lose the
cross-compilable features of jhc when using those hls depending on how
portable the code was in the first place and how clever the build system
they use is. 

This is actually less of a limitation than it seems, even if arch
specific hls are necessary, since jhc is a native cross compiler it can
just generate hls for as many different OSes and configuration options
as needed. So populating an hl repository wouldn't require wrangling
dozens of different compilation environments.

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

yeah. I have a field in the library header to indicate if it was
compiled in a platform-specific way. I don't currently set it to
anything though. it actually includes the arch flags in the computation
of the library hash, so its hash won't conflict with an incompatible
build.


> Which reminds me... is there a way to store in a .hl file what
> libraries it's to be linked with?

C libraries? if you include them in foreign imports like so

foreign import ccall "-lm math.h sinf" sinf :: Float -> Float

then they will be propegated and linked against. This obviously isn't
always ideal. What would be the best way to handle this do you think?

        John

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