I have the same problem as this guy: http://www.mail-archive.com/yhc%40haskell.org/msg00423.html I would really like to fix this. 1) it always builds the first time 2) it always fails after running scons clean This is major problem for me, because I need to clean and rebuild to make sure that my added libraries build correctly. I have installed working libs of Data.Map and dependencies including IORef on my machine, but I can't submit the patch yet because it doesn't build from scratch. As it is I have to darcs record and then darcs pull to a fresh repository. Passing stuff that I don't fully understand to xargs rm -rf does not appeal to me, [joke or anecdote about yet another accident with rm -rf]! Second question: is there a preferred way to rebuild Prelude.hi? I've been using yhc -c -rebuild -prelude Prelude.hs and copying the result into bootstrap/. Third question: is there a standard test suite for the base libraries? I couldn't find one in google. My only test so far is that 5 + 3 = 8 using modifyIORef to do the addition. My work so far is here: http://www.downstairspeople.org/darcs/yhc_clanehin
Hi,
This is problem triggered by the lastest version of scons.
To work around it simply run scons --config=force instead of just scons.
Cheers,
Andrew
On 1/11/07, Christopher Lane Hinson
I have the same problem as this guy:
http://www.mail-archive.com/yhc%40haskell.org/msg00423.html
I would really like to fix this.
1) it always builds the first time 2) it always fails after running scons clean
This is major problem for me, because I need to clean and rebuild to make sure that my added libraries build correctly. I have installed working libs of Data.Map and dependencies including IORef on my machine, but I can't submit the patch yet because it doesn't build from scratch. As it is I have to darcs record and then darcs pull to a fresh repository.
Passing stuff that I don't fully understand to xargs rm -rf does not appeal to me, [joke or anecdote about yet another accident with rm -rf]!
Second question: is there a preferred way to rebuild Prelude.hi? I've been using yhc -c -rebuild -prelude Prelude.hs and copying the result into bootstrap/.
Third question: is there a standard test suite for the base libraries? I couldn't find one in google. My only test so far is that 5 + 3 = 8 using modifyIORef to do the addition.
My work so far is here:
http://www.downstairspeople.org/darcs/yhc_clanehin _______________________________________________ Yhc mailing list Yhc@haskell.org http://www.haskell.org/mailman/listinfo/yhc
Hi
Second question: is there a preferred way to rebuild Prelude.hi? I've been using yhc -c -rebuild -prelude Prelude.hs and copying the result into bootstrap/.
Does this work reliably? Does it have a dependancy on the initial Prelude.hi file thats already there? My worry is that if you break the Prelude, then this operation may easily trash the existing .hi bootstrap file, which would mean that you couldn't then fix your error. Maybe the first thing the library builder could do is copy the existing Prelude.hi, then as the next step create a new Prelude.hi file. This way the bootstrap one just needs to provide a really small amount of stuff, and as the Prelude changes should not need modification. Thanks Neil
On Sun, 14 Jan 2007, Neil Mitchell wrote:
Hi
Second question: is there a preferred way to rebuild Prelude.hi? I've been using yhc -c -rebuild -prelude Prelude.hs and copying the result into bootstrap/.
Does this work reliably? Does it have a dependancy on the initial Prelude.hi file thats already there?
No. I encountered exactly the instance Integral problem that Dimitry just reported. I spent some time searching for the problem and couldn't figure it out. I could make a lot of half-informed observations on this issue. I'll restrict myself to this one: It seems like a design flaw that Prelude.hs is mutually dependent on several other modules. My work so far has led me to suspect that mutually dependent modules are never necessary. (And always annoying.) -- Lane
Hi Lane,
It seems like a design flaw that Prelude.hs is mutually dependent on several other modules. My work so far has led me to suspect that mutually dependent modules are never necessary. (And always annoying.)
Me and Tom came up with a solution. Write a SuperPrelude, which is the real (behind the scenes) Prelude. This includes the transitive closure of the Prelude, i.e. Ratio as well - probably split into separate files and included via cpp. Then the real Prelude is now a normal module, which just reexports various bits in SuperPrelude. This kills all renaming issues and recursive module issues in one step. We did try this, unfortunately the Yhc renamer is sufficiently broken that Prelude is a very special module, whose name shall live on forever. The renamer needs to die. As for mutually recursive modules, the make system now has support for compiling them in parallel. The parser can probably cope with this, but the type checker would die somewhat spectacularly. One day... Thanks Neil
participants (3)
-
Andrew Wilkinson -
Christopher Lane Hinson -
Neil Mitchell