Open hasufell opened 4 years ago
In GitLab by @alanz on Sep 30, 2020, 04:38
Note: putting in a symlink as
/home/alanz/.ghcup/ghc/9.0.0.20200925 -> ./9.0.1-alpha1
and then using
cabal new-configure -fdev -froundtrip --enable-tests --with-compiler=/home/alanz/.ghcup/ghc/9.0.0.20200925/bin/ghc
works as I would expect
In GitLab by @maerwald on Sep 30, 2020, 05:34
mentioned in commit 281fb14d4cd40e2f635b77fb0f0c087f8c684e67
In GitLab by @maerwald on Sep 30, 2020, 05:35
Pending action from cabal upstream: maybe we get a fix (for both old and new GHC).
In GitLab by @bgamari on Oct 6, 2020, 04:38
We discussed a variety options for addressing this on IRC last week. In short, the problem is that it was never well-defined how a build tool is supposed to find the hc-pkg
executable corresponding to a particular compiler. Cabal
currently uses various heuristics for this but these break when the executable names are changed (e.g. when the version suffix of the ghc-pkg
executable doesn't match ghc --numeric-version
).
I think the correct solution here is to introduce a means for the build tool to query the compiler for its hc-pkg
executable. Specifically, we can expose this information via ghc --info
.
In GitLab by @bgamari on Oct 6, 2020, 04:44
mentioned in issue ghc/ghc#18807
In GitLab by @bgamari on Oct 6, 2020, 04:50
I have opened ghc/ghc#18807 to track this and have implemented in ghc/ghc!4214.
In GitLab by @maerwald on May 15, 2021, 20:05
In GitLab by @maerwald on May 21, 2021, 22:53
mentioned in commit ghc/packages/Cabal@f78d2aaaa76b527f4f03032f256cf183c4ef8f5d
In GitLab by @maerwald on Aug 12, 2021, 02:01
mentioned in commit ghc/packages/Cabal@c5da1d83c91d7dafed4898814eb05629e1cd82ae
In GitLab by @maerwald on Sep 11, 2021, 01:18
This is fixed (with a hack) in cabal-3.6.0.0. It works for non-windows platforms only.
In GitLab by @alanz on Sep 30, 2020, 04:19
I installed ghc-9.0.1-alpha1 using ghcup.
Running
cabal new-configure -fdev -froundtrip --enable-tests --with-compiler=ghc-9.0.1-alpha1
on ghc-exactprint givesNote: