In message <[EMAIL PROTECTED]> Simon Peyton-Jones <[EMAIL PROTECTED]> writes: > | > Duncan, the error message I get is > | > > | > Configuring bytestring-0.9... > | > Setup: Cabal was not bootstrapped correctly > | > | This is an error from Cabal. This is bad. We get this error when Cabal does > | not > | know its own version number and so cannot compare its version number to the > | one > | that the bztestring package is requesting. > | > | So something is going wrong building Cabal and this is being triggered with > | bytestring. > > Duncan, even if cabal is at fault, the protocol is that you should validate before committing. Currently every nightly build is failing, I think.
Yes absolutely. I've had my fingers properly burnt. > Can you commit a patch which stops bytestring tickling the bug, and then go back to the right thing when cabal gets fixed? Yes, Ian an I did that at the first day of the hackathon. We discovered that the root of the problem is that the Cabal that's used in the ghc build system does not know it's own version number. This is because it does not get bootstrapped in the same way inside the ghc build as it does normally. So when a package specifies: cabal-version: >= 1.2 (like it should if it uses the configurations feature) then Cabal falls over since it cannot compare this against it's own version number, since it does not know it. The way Cabal bootstraps itself normally is that it builds the Setup.hs using it's own source code and not knowing it's version number. Then it uses it's compiled Setup.hs to configure and build itself normally. At this point it does know it's version number as it gets baked in via information in the Cabal.cabal file. > (I managed to get things working by unpulling two or three bytestring patches, but that's a bit brutal.) > > Or maybe someone can fix cabal at the hackathon. But regardless, the nightly builds should not fall over. Hopefully it's working now... So appologies about all this. I comitted what I thought was a trivial patch to the bytestring lib. I'd been unable to validate since my office sparc machine only runs an older version of ghc. As we all found out there were two bugs that were not detected by my testing with ghc-6.4.x. One was a syntax change between 6.6 and 6.8 (being stricter about , in export lits) and the other was a difference in the way libraries are built inside vs outside the ghc build system. So the moral of the story is that there are no trivial patches, not to ghc - which we all knew - and not to the core libs either, a fact some of us had not fully grasped but are now painfully aware of. Duncan _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
