Re: Add haskell-cabal build style template

Re: Add haskell-cabal build style template

[ametisf]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

New comment by ametisf on void-packages repository

https://github.com/void-linux/void-packages/pull/17198#issuecomment-599623116

Comment:
I don't think so, I don't use haskell nearly enough to justify spending the time on this now.

But you don't have to worry about that, this was concerned more with haskell developers, for applications use `build_style=haskell-stack` and just include all the dependencies in the package like the other haskell packages do. Look at pandoc or shellcheck or some other haskell package template.

Re: [PR PATCH] [Closed]: Add haskell-cabal build style template

[ericonr]

[-- Attachment #1: Type: text/plain, Size: 2281 bytes --]

There's a closed pull request on the void-packages repository

Add haskell-cabal build style template
https://github.com/void-linux/void-packages/pull/17198

Description:
I came across missing System.Random when using ghci and ended up in a pretty deep rabbit hole, it would be great to get some feedback on this before I spend even more time there.

This PR adds new build_style haskell-cabal which builds haskell packages directly using the included Setup.hs and requires neither cabal-install nor stack. It can be used for adding system-wide haskell libraries in the fashion of python, perl, ruby, etc. I know haskellers are prone to breaking a lot of their libraries, but at least very core libries like System.Random would be nice to have installed via xbps. And we could (should) just pin the versions to the ones in stackage.

Especialy I'd like to know your opinion on how to deal with the `ghc_version` variable, ghc-libs uses it to version haskell dynamic libraries and I've tried using the same locations, but that requires me to get the version number in the template and triggers. I worked around it by using globing in the trigger and running `ghc --numeric-version` which doesn't feel right, should it be just hard-coded somwhere in common/environment?

Another thing is, is it worth the effort to share common haskell packages between other haskell programs? For example shellcheck depends on parsec, which is currently linked into it's exectuable, but it's also available from ghc itself, which seems a bit wasteful.

#### TODO
- [ ] choose fitting names
    - [ ] haskell-cabal (build_style, might be confusing Cabal - library with cabal_install - cli tool)
    - [ ] ghc_package (variable, could be haskell_package, cabal_package, ...)
    - [ ] ghc_version (variable required for storing versioned ghc libraries)
    - [ ] ghc-pkg-register (the hook name)
- [ ] documentation
    - [ ] Manual.md
- [ ] fix ghc_version undefined somewhere
- [ ] undefine extra variables in subpackages
- [ ] split ghc-libs from ghc
- [ ] fix formatting (mixed tabs and spaces) and split commits properly

Pinging @leahneukirchen as you're the maintainer of ghc, if this is more suitable to discuss with someone else please forward me. Thanks :)

[ci skip]