Cabal + WinHugs + Windows + No C Compiler
ndmitchell at gmail.com
Tue Nov 7 17:24:20 EST 2006
> > * Depend on win32 - plenty of users won't have this installed (since
> > its no longer bundled by default)
> It's not? Ok, I'm a bit surprised.
MinHugs doesn't have it, the intention is to distribute GHC with less
stuff, so I doubt it will be included for much longer by default.
> > * Depend on FFI - most WinHugs users won't have C installed
> So WinHugs isn't going to support the FFI spec? It's not clear that you
> need a C compiler to support the FFI. Python and GHC can compile without
> a C compiler and still do FFI.
WinHugs indeed doesn't support the FFI spec unless you separately
install a C compiler. You can use FFI libraries that have already been
compiled, but not create new ones. GHC does this by bundling a full
copy of GCC on Windows. Python does a similar thing to Yhc by doing
wrapper less FFI - Hugs might be able to do that, but it currently
doesn't, and would be a lot of work.
> It's not something that people would really like to put into base
> because it's not portable. There really is no equivalent to
> GetModuleFileName in Unix (indeed deliberately so because you can delete
> the binary while the program is still running).
That doesn't stop people shoving in things that are Posix only :)
> I don't see a good solution apart from the current FFI solution.
The only alternative solution I can come up with is to make a Hugs
primitive on Windows, and then if you are compiling via Hugs on
Windows the Paths thing can be done without FFI. Any other thoughts?
More information about the cabal-devel