Version 4 (modified by Sascha Böhme, 10 years ago) (diff)


Enhancing the HackageDB Web Interface

Sascha Böhme, Ross Paterson { Simon Marlow, BryanOS, Bjorn Bringert, Alex Jacobson }

See the HackageDB ToDo list for a list of HackageDB tasks. (Original application to Google)

Automated building of packages and generation of Haddock documentation

The plan is for a daemon to build HackageDB packages and add the resulting build logs and Haddock documentation to the package pages. Since building Cabal packages may execute arbitrary code, it must be done in a protected environment (e.g. chroot). Currently, there are two tools for this purpose, a bash script to set up an appropriate chroot environment and a Haskell application to perform the generation of Haddock documentation.

The general idea is as follows. In the secure environment, an unprivileged user downloads a package (the work unit), inspects it dependencies from the package's Cabal file and downloads necessary dependency packages, if not already available on the system. After the dependencies have been built and their documentation was generated, the work unit is processed in the same way. During that, a build log is generated which is uploaded to the corresponding package's HackageDB website along with the package's Haddock documentation.

Other extensions of the HackageDB website

See HackageDB ToDo list, especially Package properties and Queries.



The setup_chroot script, based on debootstrap, allows to create a basic environment to build Cabal packages. It consists of GHC 6.6, Cabal 1.1.7 (taken from the darcs repository) and Haddock 0.8, along with Alex and Happy and other necessary tools. It lacks several libraries needed to build all packages currently available at HackageDB.

The autodoc tool already fulfills the above the requirements (ignoring the packages whose dependencies cannot be met, i.e. SDL and alike). In a test run, 102 package documentations could be built. For now, the tool uses the approach of cabal_install, that is, it builds all dependency packages before processing the actual package. This can be sped up by storing already built packages in the global package repository. Additionally, the autodoc tool currently relies explicitly on a chroot environment, although this is not strictly needed.

  • Todo list
    • identify C libraries needed to build packages (e.g. SDL, X11, OpenGL, ...) and add them to what the setup_chroot script is already requiring
    • rewrite the autodoc tool to use a bottom-up approach for building packages, that is, successfully built packages are stored in the system and not rebuilt again afterwards
    • remove the dependency on a chroot environment from the autodoc tool, thus improve platform-independency
    • improve autodoc output, especially more readable build logs
  • Possible extensions
    • Hoogle output
    • run test suites of packages
    • allow for different compilers and compiler versions