On Fri, Aug 29, 2014 at 10:46 AM, Joachim Breitner <[email protected]> wrote:
* Allow building of documentation when when package has no Haskell modules > ✓ > * Fix a bash bug in the dev library install recipe > ✓ > * Remove cases for binary debs in the ghc package - haskell-devscripts is > not a build dependency of ghc > While the package is not a build-dependency (which would induce too many > build dependency cycles), we _do_ use ./dh_haskell_provides in GHC, > after copying it there. So this code needs to stay. > Ok > * Remove support for obsolete doc package prefix "haskell-" > ✓ > * Pass --package-db to the cabal configure command > ✓, but why? > This has so far been necessary for building ghcjs libraries. > * Pass --with-haddock and --with-ghc to cabal haddock > again ✓, but why? What does this change? > This is also required by ghcjs - it has its own ghcjs-pkg and haddock-ghcjs executables. > * Add functions to Dh_Haskell.sh to parse library package names, compute > compiler names and compiler dependent paths > You use “ghc -e” which requires GHCi which is not available on all > architectures, so this is not good. > The proper way to do it is to parse the output of "ghc --info". > I’m pulling it for now. > I will try to make this change. > * Move the make recipes from hlibrary.mk to Dh_Haskell.sh > Nice cleanup > * Add a postinst script to the ghcjs dev library to run recache > Shouldn’t this be handled by a dpkg trigger in your ghcjs package? > Not pulling. > Yes, I would appreciate some guidance on how to do this. > It looks like not pulling > * Remove cases for binary debs in the ghc package - haskell-devscripts > is not a build dependency of ghc > prevents me from pulling these patches: * Large patch to parameterize the name of the haskell compiler in order > to support ghcjs > * Add duplicates of the libghc rules modified to build libghcjs > packages > * Remove set -x directives in hlibrary.mk > * Add improved debugging code (disabled) > * Supply default compiler to packages_hc call in dh_haskell_blurbs. > I’m afraid that this means that the patches I did pull left me with > something broken. > > Not sure how we should proceed from here. Do you want to integrate my > review until I’m satisfied with the overall result, which I then can > pull in one go? > Yes, I will create revised patches. Is it too late for you to unpull? > > > I see that os() and cpu() are only used when building ghcjs packages. > But still, reading that data from ghc --info is saner. Or maybe even > from dpkg-architecture. > > > Greetings, > Joachim > >
