On Fri, Jun 15, 2007 at 03:19:18PM +0100, Neil Mitchell wrote:
Hi
That you mention this *now* implies that Malcolm is having issues with libgmp as well as libffi, which means that (per your plan mentioned on IRC yesterday) Malcolm will get 32 bit Integers. Why didn't he have this problem with nhc?
Libraries, build system, makefile vs scons - its not incredibly well understood. Malcolms machine is also not able to become a buildbot (its behind a firewall) and is a 64 bit Mac (I think) - if someone could provide us with such a buildbot we'd have a better chance at diagnosing it.
Why is that an issue? I thought buildbots communicated using email.
3) Libraries: We need to move to the Haskell.org libraries. This may mean increasing our build stuff, or moving to Cabal.
Increasing our build stuff, maybe not; I'm a strong opponent of GHC's extralibs :)
I mean our build infrastructure, not building more libraries by default necessarily - just allowing it to be done.
Ah, ok.
Supporting Cabal is an absolute must if we want to take over any sizable chunk of the Haskell implementation's market; for implementation I recommend http://haskell.org/pipermail/libraries/2007-May/007507.html.
Waiting for Cabal improvements may slow things down a lot. Cabal is obviously a very nice way to go, but may require lots of hacking to Cabal - which isn't the worlds nicest code base. If someone stepped forward saying that really like hacking Cabal and wanted to use Yhc as a case study that would be great!
It might be an issue, that yhc unlike nhc cannot generate executables. We should look at what Hugs' cabal support uses.
I don't think so, unlikely Hugs we can generate something that's nearly an executable, and we can go closer (bytecode linking) if necessary.
Not sure I understand - how does runhugs Foo.hs differ from yhi Foo-linked.hbc, from an API standpoint? Stefan