From: ericonr <ericonr@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [PR PATCH] [Closed]: Add haskell-cabal build style template
Date: Sun, 01 Nov 2020 03:15:00 +0100 [thread overview]
Message-ID: <20201101021500.s4tgxT1HR4BiM_8LanKgJf2IJVS36qAVoGyYdXP07s4@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-17198@inbox.vuxu.org>
[-- 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]
prev parent reply other threads:[~2020-11-01 2:15 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-17198@inbox.vuxu.org>
2020-03-16 16:10 ` ametisf
2020-11-01 2:15 ` ericonr [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201101021500.s4tgxT1HR4BiM_8LanKgJf2IJVS36qAVoGyYdXP07s4@z \
--to=ericonr@users.noreply.github.com \
--cc=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).