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/