haskellPackages.postgresql-libpq-configure: unbreak

[cdepillabout]

This gets the two haskell packages postgresql-libpq-configure and postgresql-libpq-pkgconfig building.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[sternenseemann]

Don't we also need psotgresql in library depends additionally?

[wolfgangwalther]

Is this enough to build postgresql-libpq_0_11_0_0 with the use-pkg-config flag, which we currently do with postgresql-libpq in configuration-nix.nix?

I think it's not, yet. I went down that rabbit hole yesterday - the flag would need to be set for cabal2nix, to generate the right dependencies in hackage-packages.nix. Which lead me to the fact that flags are hardcoded in the cabal2nix repo, which lead to... aahhh. Why?

It would be really cool if cabal2nix wouldn't just use one flag hardcoded, but would output an expression with conditionals instead.. something like:

  "postgresql-libpq_0_11_0_0" = callPackage
    ({ mkDerivation, ...
     , usePkgConfig ? false
     }:
     mkDerivation {
       ...
       libraryHaskellDepends = [
         base bytestring unix
       ] ++ lib.optionals usePkgConfig [ postgresql-libpq-pkgconfig ]
       ++ lib.optionals (!usePkgConfig [ postgresql-libpq-configure ];
       ...
     }) {};

With that system we could also support cross-compiling better because if os(windows) etc. could be transformed into conditional expressions based on stdenv.hostPlatform...

Ok, anyway, back to reality - how can we fix it here, so that postgresql-libpq will continue to use the pkg-config approach for better cross-compilation?

[wolfgangwalther]

Seems like this has been done in 7b995f0.

[sternenseemann]

@wolfgangwalther Unfortunately, cabal2nix uses BuildInfo as a basis for the generated expressions. BuildInfo is the result of configuring, so all flags are already fixed. So cabal2nix doesn't actually have the information available to generate Nix conditionals for cabal conditionals.

I agree that it would interesting to be able to generate expressions like that, but unfortunately it seems that we would to more or less completely reengineer cabal2nix to make this possible.

On the amount of hardcoded stuff in cabal2nix, see also NixOS/cabal2nix#504. I think the solution is probably to make all these hardcoded things configurable, e.g. NixOS/cabal2nix#594.