Can't compile GHC-7.8.3 from git, fails on haskell98 library

Hi, On a completely clean clone, I've checked out the tag ghc-7.8.3-release, ran sync-all get, boot, and configure, but the build fails on haskell98. Any ideas what I could be doing wrong? Thanks, Gergo "inplace/bin/ghc-cabal" check libraries/haskell98 "inplace/bin/ghc-cabal" configu

Re: [commit: ghc] wip/T9705: Add test case for T9705 (1cca652)

On Sat, 1 Nov 2014, Gabor Greif wrote: Hello Gergö, you seem to test pattern synonyms in _class_ declarations here. Would it make sense to also test _instance_ declarations? Excellent point. I've added a separate test for that, and also this made me notice that the error message only mention

Re: How to treat testsuite timeout as success?

Probably the easiest thing to do is write a little stub program which calls the actual test with a timeout. Edward Excerpts from Merijn Verstraaten's message of 2014-11-01 16:01:35 -0700: > Ola! > > I was trying to re-re-fix https://ghc.haskell.org/trac/ghc/ticket/8089 and > add a test-case for

How to treat testsuite timeout as success?

Ola! I was trying to re-re-fix https://ghc.haskell.org/trac/ghc/ticket/8089 and add a test-case for this fix. However, I'm having trouble creating a test that can actually be successful. The simplest case exhibiting the issue (on OSX) is that "main = threadDelay maxBound" crashes, I need a way

Re: Proposal: Improving the LLVM backend by packaging it

On 2014-11-01 at 18:43:35 +0100, Ben Gamari wrote: [...] >> This would mostly hurt if you cleaned up the tree later (e.g. 'make >> distclean'), which I do rather frequently in order to get a pristine >> build tree. >> > Ideally `make clean` would be a bit more complete so it could be used > more

Re: Proposal: Improving the LLVM backend by packaging it

On 2014-11-01 at 17:26:26 +0100, Austin Seipp wrote: [...] >> How long does building those two llvm binaries take? If it is >> sufficiently quick, maybe that would be a suitable distribution for >> developers as well, and avoids having to separately build, distribute, >> download, and install the

Re: Proposal: Improving the LLVM backend by packaging it

Austin Seipp writes: > On Sat, Nov 1, 2014 at 11:12 AM, Joachim Breitner > wrote: >> Hi, >> >> for the Distributions it would be most easy if the custom llvm would >> come within the source tarball, would be built by the regular build >> process and installed along with GHC, in a private path >>

Re: Proposal: Improving the LLVM backend by packaging it

Austin Seipp writes: > On Sat, Nov 1, 2014 at 10:43 AM, Ben Gamari wrote: >> >> I'm certainly not opposed to this idea and there is precedent in this >> area set by the Rust folks. That being said, I suspect some >> distributions may care pretty deeply about being able to compile against >> thei

Re: Proposal: Improving the LLVM backend by packaging it

Austin Seipp writes: > Joachim, thanks for the forward and discussion. > > Just to rehash two points for the people reading at home: > > - I *do not* want to ship GHC specific patches to LLVM in the builds > we use, anymore than anyone else does. I don't have any plans or even > patches I would

Re: Proposal: Improving the LLVM backend by packaging it

Hi, Am Samstag, den 01.11.2014, 11:26 -0500 schrieb Austin Seipp: > > How long does building those two llvm binaries take? If it is > > sufficiently quick, maybe that would be a suitable distribution for > > developers as well, and avoids having to separately build, distribute, > > download, and

Re: Proposal: Improving the LLVM backend by packaging it

On Sat, Nov 1, 2014 at 11:12 AM, Joachim Breitner wrote: > Hi, > > Am Samstag, den 01.11.2014, 11:05 -0500 schrieb Austin Seipp: >> > Do you envision that LLVM always be built alongside GHC when bringing up a >> > new working tree? >> >> No - on Tier 1 platforms, I suggest we always provide binar

Re: Proposal: Improving the LLVM backend by packaging it

Joachim, thanks for the forward and discussion. Just to rehash two points for the people reading at home: - I *do not* want to ship GHC specific patches to LLVM in the builds we use, anymore than anyone else does. I don't have any plans or even patches I would apply right now. A stock LLVM is id

Re: Proposal: Improving the LLVM backend by packaging it

Hi, Am Samstag, den 01.11.2014, 11:05 -0500 schrieb Austin Seipp: > > Do you envision that LLVM always be built alongside GHC when bringing up a > > new working tree? > > No - on Tier 1 platforms, I suggest we always provide binary packages > for developers to grab. Those same binaries would be

Re: Proposal: Improving the LLVM backend by packaging it

On Sat, Nov 1, 2014 at 10:43 AM, Ben Gamari wrote: > Austin Seipp writes: > >> Hi *, >> >> A few days ago a discussion on IRC occurred about the LLVM backend, >> its current status, and what we could do to make it a rock solid part >> of GHC for all our users. >> >> Needless to say, the situation

Re: Proposal: Improving the LLVM backend by packaging it

Hi, Am Samstag, den 01.11.2014, 11:43 -0400 schrieb Ben Gamari: > I'm certainly not opposed to this idea and there is precedent in this > area set by the Rust folks. That being said, I suspect some > distributions may care pretty deeply about being able to compile against > their own LLVM packagi

Re: Proposal: Improving the LLVM backend by packaging it

Austin Seipp writes: > Hi *, > > A few days ago a discussion on IRC occurred about the LLVM backend, > its current status, and what we could do to make it a rock solid part > of GHC for all our users. > > Needless to say, the situation right now isn't so hot: we have no > commitment to version su

Porting to Haiku

Hi, I (and one other) am working on porting GHC to Haiku; we've successfully got a working GHC cross-compiler running on Haiku, and now are able to also build GHC on Haiku from the cross-compiler when using the "quickest" profile in the mk/build.mk file. However, using the default build profile,

Re: [commit: ghc] wip/T9705: Add test case for T9705 (1cca652)

Hello Gergö, you seem to test pattern synonyms in _class_ declarations here. Would it make sense to also test _instance_ declarations? Cheers, Gabor On 11/1/14, g...@git.haskell.org wrote: > Repository : ssh://g...@git.haskell.org/ghc > > On branch : wip/T9705 > Link : > http://ghc.

Re: Proposal: Improving the LLVM backend by packaging it

I think this is a great idea. My understanding from the wiki page is that the full plan involves: 1. We need to *fix compatibility with recent LLVM versions*. This really sucks for users. *Ben Gamari* is working on this, see #9142 and ​Phab: