-
Notifications
You must be signed in to change notification settings - Fork 845
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix cabal build
by freezing cabal dependencies
#5677
Conversation
cabal build
by freezing cabal dependencies
FYI, this PR fixes the major issue with |
- Fixed building from source. Due to recent update of aeson-2.0.0.0, stack can no longer be built with cabal-install. So I patched stack to freeze cabal dependencies using stackage 17.15 LTS. - Add Apple Silicon support. HEAD version of stack has already been patched to support Apple Silicon. However, the next release containing that patch hasn't release yet. So I manually patched stack v2.7.3 to support Apple Silicon. - Add llvm@12 as a dependency only on ARM All ghc versions before 9.2.1 requires LLVM Code Generator as a backend on ARM. Fixes Homebrew#94796 Reference: commercialhaskell/stack#5562 commercialhaskell/stack#5677
- Fixed building from source. Due to recent update of aeson-2.0.0.0, stack can no longer be built with cabal-install. So I patched stack to freeze cabal dependencies using stackage 17.15 LTS. - Add Apple Silicon support. HEAD version of stack has already been patched to support Apple Silicon. However, the next release containing that patch hasn't release yet. So I manually patched stack v2.7.3 to support Apple Silicon. - Add llvm@12 as a dependency only on ARM All ghc versions before 9.2.1 requires LLVM Code Generator as a backend on ARM. Fixes #94796 Reference: commercialhaskell/stack#5562 commercialhaskell/stack#5677
@borsboom Any chance to get this reviewed/merged? |
b2a2e56
to
fc95a26
Compare
To easily package stack to various distributions, one should be able to bootstrap stack without relying on stack binary. So many package maintainers use cabal-install to build stack from source code. Due to recent update of aeson-2.0.0.0, stack can no longer be built with cabal-install. So I hereby send a PR to freeze cabal dependencies using stackage 17.15 LTS. Reference: https://hackage.haskell.org/package/stack2cabal
fc95a26
to
2daa257
Compare
I've tested this locally and can
|
Is the original problem - cannot use Cabal (the tool) to build Stack - still a problem? You mention |
I'm closing this PR as this patch is now outdated, but we steel do need a way to create a reproducible build without depending on |
I use stack2cabal (on hackage) to build stack with cabal. It creates freeze file and cabal.project from stack.yaml. |
Yeah this PR was to embed freeze file into this package not to depend on stack2cabal. |
I agree it's worthwhile, but then there also should be post commit hooks or something that check these don't diverge. |
I asked myself: What stops Cabal (the tool - I'll refer to it just as 'Cabal') from being able to build Stack? Was there something about Stack's After a little investigation, I think it is simply that Cabal needs to be told about an upper bound on the
resolver: lts-18.28 # cabal-install requires base < 4.15
packages:
- .
extra-deps:
- Cabal-3.6.3.0 # cabal-install requires Cabal >= 3.6.1.0
Which, as an aside, does not mean anything to me.
Success! I'll raise a pull request to put that constraint on |
…ge.yaml` Stack advises that it should be built with Stack, but some users wish to use Cabal (the tool) to build Stack. This is possible if the upper bound on `persistent` is specified.
Fix #5677 Add upper bound for `persistent` in `package.yaml`
To easily package stack to various distributions, one should be able to bootstrap stack without relying on stack binary. So many package maintainers use cabal-install to build stack from source code.
Due to recent update of aeson-2.0.0.0, stack can no longer be built with cabal-install. So I hereby send a PR to freeze cabal dependencies using stackage 17.15 LTS.
Reference: