Hi Austin, > Essentially everything is coming down to the build system it looks > like. The basic idea is to go from autoconf -> Cabal as I see it. > What is this new system buying us? Because currently, it seems to have > cost us: > > 1. Parallel builds (i.e. make -j, brought up by ChilliX) > 2. A working build system (and by association a buildable HEAD) > > Why the switch to a cabal infrastructure? To stress test it? To make > building simpler (i.e. win32)? To prove a point? What's the end result > and what do we hope to gain? The old build system wasn't broke; why > fix it?
(The parallel builds comment confuses me: certainly I can still build the compiler in parallel, though the libraries were always Cabal based and hence compiled sequentially). I believe one of the things we gained is the ability to run Haddock on GHC itself. However, I agree that the new system has had (and is still having) teething troubles: for example, some of my dynamic linking code assumed the cProjectVersion corresponded to the version number being used to build the GHC library, but this seems to have remained an unimplemented feature. Would it have been possible to bake the Cabalisation a bit more thoroughly >off< the HEAD and then merged it in in a "big bang"? That would have presented other developers a single chunk of work to do to fix their own branches given the change, which is probably less painful than the current death by a thousand cuts :-) > (From the frusteration Mr. Chakravarty has expressed, it seems as > if it magic'd itself in there: non-existant one minute, full blown the next.) > > With these changes other things also seem to be falling down as well; with > the most recent checkout of GHC, it does not even fail with the err I > had a few days ago about the 'inferred architecture size ... i386', it > fails with this: The "inferred architecture" thing was due to a patch by Simon Marlow (who runs Windows) not playing well with OS X. >> Preprocessing executables for ghc-pkg-6.9... >> Building ghc-pkg-6.9... >> [1 of 1] Compiling Main ( HaskTags.hs, >> dist-install/build/hasktags/hasktags-tmp/Main.o ) >> [1 of 1] Compiling Main ( runghc.hs, >> dist-install/build/runghc/runghc-tmp/Main.o ) >> [1 of 1] Compiling Main ( installPackage.hs, >> dist-install/build/installPackage/installPackage-tmp/Main.o ) >> [1 of 2] Compiling Version ( Version.hs, >> dist-install/build/ghc-pkg/ghc-pkg-tmp/Version.o ) >> [2 of 2] Compiling Main ( Main.hs, >> dist-install/build/ghc-pkg/ghc-pkg-tmp/Main.o ) >> Main.hs:1143:14: Not in scope: `Exception.onException' I haven't seen this. FWIW the HEAD built for me on OS X 10.5 on Saturday (I haven't tried more recently), though I had some trouble due to not distcleaning before a pull. > Which ChilliX pointed out should have been caught by the validate > script; so how did this patch get through? It is completely > unpredictable at this point in time where things are going to break, > how and for what reason. Pretty flaky, to be honest. > > The question in full is: what in the hell is really going on right > now? Is it simply project-management practices or true technical > issues that must be dealt with using hard, cold debugging and a good > injection of code? I'm wagering it's somewhere inbetween the two from > the view I'm getting from my binoculars. > > What *is* going on, and more importantly, -how can we help improve the > situation-? Right now, I've no idea where to start and without help > from you guys, I doubt anybody else can, considering you guys are > -it-. So please, speak. What is going on? How can the would-be's like > myself get involved and help? What is the state of the breakage, and > more importantly it's reason? OS X support has always been a problem. Personally I've never managed to get a clean validate run on OS X. Perhaps an OS X build bot would be helpful, but the bots seem to be so pervasively broken that it doesn't get the impression that anyone is paying attention to them any longer. Neil's idea for a staged commit to HEAD (mentioned later in this thread) seems quite attractive, but it requires yet another moving part in what is already quite a complicated development system. Perhaps something like being able to: 1) Publish your repo is a publically accessible location 2) Use a website to request the buildbots try out that repo 3) The buildbots download + build that repo and send you email with their results would help, without inserting yet more automated stuff into the commit process. Of course, this requires working buildbots! It might also be more workable with a non-Darcs VCS because you could push your local branch to the GHC repo without merging it to HEAD, so the buildbots would just need to switch branches rather than pull a whole new repo to do this process. All the best, Max _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
