On Sun, Mar 01, 2009 at 11:03:41PM +0000, Duncan Coutts wrote:
They serve different purposes, hsc2hs is meant to run on the actual machine the library is being _built_ _for_ to obtain information that is only available on the final build architecture/operating system. as in, an hsc file is the lowest level portable code you can write. c2hs is more of a developers tool. If anything, I think c2hs should generate hsc files, which can then be portably distributed.
Like hsc2hs, c2hs has to be run using the C headers for the target machine. It needs these to calculate struct sizes like hsc2hs does. The reason it cannot generate .hsc files and leave the rest to hsc2hs is that it also generates Haskell ffi imports. It imports the C functions at the correct Haskell types. If the C headers on a different platform are quite different then we will get a type error at compile time. With hsc2hs we'll just get a segfault. So c2hs and hsc2hs are in the same class here. They both must be run for the target machine.
It still seems like you can get almost all the way there by generating things like (#type guint) in the hsc file. You would not be able to work around APIs that actually differ between architectures, but those are not all that common beyond the inherent incompatabilities due to C calling conventions and structure layouts. As in, you should be able to produce portable hsc files for everything that we could have written portable C code for in the first place, which is a large percentage of libraries. The other reason it would be nice is then we have a clear seperation of concerns, c2hs would just need generic header files, while hsc2hs requires an actual target build environment. Allowing people to build projects that used c2hs with just hsc2hs and not having to install c2hs in the majority of cases. The other reason is that it means that cross compiler support only needs to be implemented in one place, whatever interprets the hsc file. For instance, jhc is a cross compiler by nature, a mac OSX binary created on a linux box is equivalent to one you would create sitting at the mac OSX box and compiling it natively. Generally, bringing this about is quite straightforward, ; jhc --progc i386-mingw32-gcc -mgeneric HelloWorld.hs -o HelloWorld.exe ; wine HelloWorld.exe Hello, World! but when you involve hsc files things get a bit trickier, since it requires not just having access to the appropriate compiler, but the ability to run the resulting program. I'd like to remove that requirement, my current plan was to have jhc natively and transparently handle hsc files just like hs files. a (#type guint) will propagate through all the passes and actually become a 'guint' in the generated C file, likewise, for (#const ..) and other hsc declarations. As in, I am treating hsc files as a sort of standard way to express cross platform C compatability that all compilers should support (either natively or via hsc2hs) rather than specific input to hsc2hs. John -- John Meacham - ⑆repetae.net⑆john⑈