Good work David. I used to do something like this for Cabal regression testing but the method I used didn't scale well as hackage grew. I'll look into using your tool next time for testing a major Cabal / cabal-install release.
Duncan On 23 April 2012 21:37, David Terei <dave.te...@gmail.com> wrote: > Hi all, > > I've updated the old hackage-test tool and renamed to hackager. > > http://hackage.haskell.org/package/hackager > > Hackager is a tool to automate the compiling of all packages on > Hackage. It builds each package on hackage in isolation and records > the results. The purpose being to catch regressions caused by changes > to GHC (and Cabal although this was not the motivation). Two runs of > Hackager can be compared, so the first run is done with a known > version of GHC and the next run with a new, experimental version of > GHC... ect. > > The improvements to Hackager over hackage-test are: > * Parallelized the build process. Can now specify how many packages to > build in parallel, which cuts total run time down greatly (e.g 2 days > -> 5 hours) > * hackage-test and hackage-report are now one tool, 'hackager' that > works as a mutli-command tool. > * Proper option handling > * Fixed some stability issues > > The new homepage for development can be found here: > https://github.com/dterei/Hackager > > Cheers, > David > > _______________________________________________ > Haskell-Cafe mailing list > haskell-c...@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel