search

haskell / cabal

Official upstream development repository for Cabal and cabal-install
https://haskell.org/cabal
Other
1.61k stars 691 forks source link

Make ghc-pkg discoverable from ghc executable #7390

Open bgamari opened 3 years ago

bgamari commented 3 years ago

Describe the bug Currently there is no robust way to locate the ghc-pkg executable corresponding to a particular compiler. For this reason, Cabal currently implements a variety of heuristics to do the same. However, these can end up failing, in particular when the executable name is version-suffixed.

@hasufell and I discussed this some months ago after a ghc-up user encountered this problem, which resulted in GHC #18807. To address this I proposed that ghc --info should report the path to the corresponding ghc-pkg executable. This solves the problem nicely since Cabal already must query --info when configuring a package.

I have put together a very straightforward GHC implementation as !4214. I have also written a quick patch implementing the Cabal support.

My sense is that this is the right solution to the problem. However, I'm also happy to hear alternatives. If there are no objections, I will backport to 8.10.5, 9.0.2, and 9.2.1 such that future users won't encounter this issue in the future.

phadej commented 3 years ago

Does this supersede/obsoletes https://github.com/haskell/cabal/issues/6648 or are both valuable?

hasufell commented 3 years ago

I'll try the patch out tomorrow in conjunction with the GHC patch.

I also noticed that we could investigate another workaround in the following function

https://github.com/haskell/cabal/blob/4f8aeb2c8a0a3638e1af887dc869a17e291c8329/Cabal/src/Distribution/Simple/GHC.hs#L267-L278

What if we canonicalize first and then effectively follow the symlink if it is one... that would make us usually end up in the internal ghc directory, which should always work. No?

The advantage of this would be that it's a backwards compatible fix that doesn't need a GHC patch.

@rvl do you know if this could break a nix use case?

phadej commented 3 years ago

@hasufell, that would work. On my machine

Prelude System.Directory> canonicalizePath "/opt/ghc/bin/ghc"
"/opt/ghc/8.6.5/bin/ghc-8.6.5"

Prelude System.Directory> canonicalizePath "/opt/ghc/bin/ghc"
"/opt/ghc/8.6.5/bin/ghc-8.6.5"

I think both ghc --info and your canonicalizePath proposal will break nixpkgs if they (re)wrap ghc-pkg and rely on $PATH, yet if they pass --with-hc-pkg explicitly, then it shouldn't break.

bgamari commented 3 years ago

Does this supersede/obsoletes #6648 or are both valuable?

I think they are essentially duplicates. I just didn't find #6648 until I had already opened this one.

Mikolaj commented 1 year ago

How can we help to move this forward? @bgamari, are your patches alive?

andreabedini commented 1 year ago

Just go out of curiosity, in what cases ghc-pkg path is not the the same as ghc plus -pkg?

phadej commented 1 year ago

Just go out of curiosity, in what cases ghc-pkg path is not the the same as ghc plus -pkg?

Yes, one could look for suffix etc, but that is a hack (heuristic in OP) which has shown to be unreliable.

phadej commented 1 year ago

FWIW, ghc should also make other stuff discoverable through --info, e.g. the haddock. (It's very hard to build docs with not bundled haddock, I doubt non-haddock-developers are actually ever doing so).

andreabedini commented 1 year ago

Thank you @phadej