Use cabal 3.8

[hamishmack]

A bug was fixed in cabal (haskell/cabal#6771) that haskell.nix relied on for pkg-config in support. To work around this we added a dummy pkg-config that cabal configure now uses when haskell.nix runs it cabal configure internally. That returns version information for all the pkg-config packages in lib/pkgconfig-nixpkgs-map.nix. This mapping has also been expanded based on the results of searching nixpkgs for *.pc files.

This PR also includes workarounds for:

haskell/cabal#8352
haskell/cabal#8370
haskell/cabal#8455

Due to the number of materialization changes in this commit the GitHub make sure to scroll down to to see overlays and modules code changes (unfortunately you will have to click Load diff).

[hamishmack]

bors try

[hamishmack]

bors try-

[hamishmack]

bors try

[iohk-bors]

try

Build failed:

• buildkite/haskell-dot-nix

[hamishmack]

bors try

[iohk-bors]

try

Build failed:

• buildkite/haskell-dot-nix

[hamishmack]

bors try

[iohk-bors]

try

Build failed:

• buildkite/haskell-dot-nix

[hamishmack]

bors try

[iohk-bors]

try

Build failed:

• buildkite/haskell-dot-nix

[hamishmack]

bors try

[iohk-bors]

try

Build failed:

• buildkite/haskell-dot-nix

[hamishmack]

bors try

[hamishmack]

I have updated the change log, top comment and PR title to include the new pkgconfigSelector project argument (required now for projects that rely on pkgconfig-depends).

[hamishmack]

I also added haskell/cabal#8455 to the list of cabal issues this PR works around.

[angerman]

I still liked the buggy behaviour more. It required less manual intervention. Though I guess this is fair.

If cabal fails to find a pkg-config package, what will it do? Can we sensibly tell people to add those things to the pkgconfig selector?

[hamishmack]

If cabal fails to find a pkg-config package, what will it do? Can we sensibly tell people to add those things to the pkgconfig selector?

It depends a bit on the project. In some cases cabal will fall back on a plan that does not require the package version or uses a different automatic flag. When it does give an error it looks like this:

Error: cabal: Could not resolve dependencies:
[__0] next goal: libsodium (user goal)
[__0] rejecting: libsodium-1.0.18.2 (conflict: pkg-config package
libsodium>=1.0.18 && <=1.0.18, not found in the pkg-config database)
[__0] rejecting: libsodium-1.0.18.1, libsodium-1.0.18.0 (constraint from user
target requires ==1.0.18.2)
[__0] fail (backjumping, conflict set: libsodium)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: libsodium

We could perhaps add code to parse cabal configure error output and give hints.

[hamishmack]

Perhaps we could create an open haskell.nix issue conflict: pkg-config package X, not found in the pkg-config database with instructions on how to use pkgconfigSelector = p: [ p."X" ]; to fix it. At least then googling the error might be helpful.

[hamishmack]

BTW I looked into using another pkg-config wrapper for this problem, but cabal gets all the versions up front with pkg-config --list-all and pkg-config --modversion.

I think the only good way to improve the error message is with a patch for cabal.

[michaelpj]

Better to augment the troubleshooting page in the docs? I do agree that it's nice if this can be more automatic, but if it can't then we may have to live with it. Do you have to provide dependencies for your transitive deps? How do packages from hackage work?

[ramirez7]

Do you have to provide dependencies for your transitive deps?

+1 to this Q. If I have a dependency on, say, sdl2 - what will happen if I bump haskell.nix to this? I assume I'll need SDL2 in pkgconfigSelector. But what about when sdl2 the Haskell library is built?

---

Out-of-scope thoughts & questions:

It would in theory be possible to parse the cabal file before the planning stage and use that to guess at pkgconfig-depends, correct? I assume callCabal2Nix does this sort of thing already.

But maybe that's out-of-scope for haskell.nix. It could probably be a separate Nix function and used to set pkgconfigSelector. But maybe there's a case to integrate that functionality in haskell.nix since it would have to be done for all dependencies.

As-is in this PR, it's not the most annoying thing. But it is a step back and definitely worse for the end-user than nixpkgs Haskell infra (one big thing people seem to like is not running into the "what C libraries do I need?" problem)

[ramirez7]

I have a MR for bumping my Haskell gamedev Nix library to this PR: https://gitlab.com/macaroni.dev/macaroni.nix/-/merge_requests/10

I re-read these comments, and I realized I just need to include all my C deps in my cabalProject invocation.

[L-as]

This is a very big breaking change, no? What's wrong with just partially reverting the patch in question?

[hamishmack]

This is a very big breaking change, no? What's wrong with just partially reverting the patch in question?

Its a fairly significant bug in haskell.nix that it does not choose an accurate plan based on the available pkg-config package.

[hamishmack]

@yvan-sraka and I came up with a better fix that does not require pkgconfigSelector. Instead it relies on the .version of the available pkg-config packages in nixpkgs.

[hamishmack]

For people in the future wondering (what are they talking about?) here is the description of the pkgconfigSelector that we don't think we need now (so I am going to remove it from the top comment):

A pkgconfigSelector must now be passed to cabal projects that have pkgconfig-depends. Use the pkg-config names. For instance if the project uses gi-gtk pass:

pkgconfigSelector = p: [ p."gtk+-3.0" p."gobject-introspection-1.0" ];

The dependencies of gtk will be included automatically.

Why?

Cabal 3.8 fixes a bug haskell/cabal#6771 that haskell.nix relied on (probably wrongly), to create a plan for a haskell project without knowing the pkg-config versions available ahead of time.

This was probably a bad idea.

We could try to provide every pkg-config derivation in nixpkgs to the derivation that generates the cabal plan. Unfortunately:

• That would introduce a massive dependency tree to the plan-nix
  dervaition.
• Some of those packages may not build.

The pkgconfigSelector allows haskell.nix to filter out only the packages we need from the available map (lib/pkgconf-nixpkgs-map.nix).

It should be thought of as the haskell.nix equivalent of installing your pkg-config dependencies before running cabal build.

[michaelpj]

I think it would be worth elaborating on this a bit - I think there's quite a bit of latent knowledge here!

[hamishmack]

Yes more docs to come. I'm still working out what to do about the implicit mapping of pkg-config names to nixpkgs names (we probably can't keep that). Currently I have a script trawling through nixpkgs for .pc to make a more accurate mapping file.

[hamishmack]

I've tried to expand this comment a bit.

[hamishmack]

bors try

[iohk-bors]

try

Build succeeded:

• ci/hydra:Cardano:haskell-nix:required
• buildkite/haskell-dot-nix