…tVersions from HackageTranslation These functions are used in client-code, and I don't know a better place for them.
…ps' code These modules need more polishing before they can be become part of the officially published API.
…_PROFILING In order to enable building of profiling libraries, set the environment variable PKGBUILD_HASKELL_ENABLE_PROFILING to any non-empty string, i.e. "1", "0", "yes", or "no". To disable support, undefine PKGBUILD_HASKELL_ENABLE_PROFILING (or set it to an empty string). These semantics feel slightly more robust than expecting the user to specify a specific value, a number even, to turn this feature on. By default, that environment variable is undefined, so profiling libraries are off by default. For those who are running chroot builds -- i.e. by means of the makeworld script shipped in HABS --, please note that the shell environment of the caller will not be exported into the chroot build environment! As of now, it seems like the only way to enable profiling in chroot builds is to add an assignment of the variable PKGBUILD_HASKELL_ENABLE_PROFILING to /etc/makepkg.conf (in the chroot environment).
The problem: Some Arch Haskell developers rely on profiling their programs, which in turn rely on certain Haskell AUR packages. Previously, these packages did not have profiling enabled in their PKGBUILDs, which meant that those who wanted profiling had to rebuild all packages in the dependency chain that did not have profiling enabled. The solution: This one-liner simply adds in a Bash conditional statement into the default PKGBUILD for haskell library programs. The statement depends on the new $PKGBUILD_HASKELL_ENABLE_PROFILING variable having a value "1". E.g., "export PKGBUILD_HASKELL_ENABLE_PROFILING=1". An Arch Haskell user can now export this variable in his ~/.bashrc or somewhere else, which will trigger the conditional statement to enable profiling. This way, only those users who want profiling will get it, and it will not affect anyone who does not care about profiling.
It's particularly nice to be able to drop the module Paths_archlinux, because without that this code be easily run outside of the Cabal build system, i.e. from ghci.
Cabal library, it can be used to favour a particular dependency version in the resulting PKGBUILD.
bindings) but under /usr/lib/ghc-*/site-local.
Building libraries with --enable-shared is simple enough, but unfortunately Cabal doesn't take advantage of shared libraries when linking executables (even when --enable-shared is specified). Having shared libraries available is beneficial anyway, though, because ArchLinux users may choose to build their binaries with '--dynamic'.
…a dot. This change means that '.git' will be ignored as well as '.' and '..'.
The archlinux library should not make claims about who was responsible for the generation of a PKGBUILD. It might have been cabal2arch, but it might have been something else. This code is generic: we want it to be re-used by other tools. Consequently, a "generated by" line should be inserted by the tool that uses the library.
…r errors. Previously, the function return 'Nothing' in case of a parser error even though a more accurate error description was available. Instead, it now uses 'fail' to report that error.
Our PKGBUILD files feature a comment saying that we provide all package dependencies and that the user's front-end to pacman must understand 'provides'. In fact, this is not true: we no longer specify dependencies on packages that are provided by GHC. Instead of that comment, I feel we should provide a Maintainer: field, which -- according to namcap -- is currently missing.