Use pkg-config first, then fall back to pg_config

[develop7]

Since recent releases of PostgreSQL using pg_config for non-server extensions is discouraged. This is why pg_config gets phased out of client library development packages.

Therefore it should be quite safe to try pkg-config before pg_config, since the latter may even not be present in the system.

1: https://bugzilla.opensuse.org/show_bug.cgi?id=1140408#c1

[phadej]

What's the solution for finding PostgreSQl libs on windows if pg_config is phased out?

[develop7]

What's the solution for finding PostgreSQl libs on windows if pg_config is phased out?

If I understood https://cabal.readthedocs.io/en/latest/developing-packages.html#pkg-field-flag-manual correctly, removing manual stanza makes cabal try both flag values, effectively falling back to pg_config instead of hard fail otherwise.

On Windows it is common to install all development-related stuff together, without the -client and -server split (EnterpriseDB does that), therefore I have firm belief Windows users will not be affected, since pg_config will be there anyway.

[phadej]

Someone have to test this on windows (i.e. that cabal-install solver in fact backtracks when pkgconfig-depends aren't satisfiable).

I won't have an access to a machine for some time

[develop7]

Someone have to test this on windows

I've tested if it would fallback on Linux first, and (spoiler) it didn't. I've uninstalled postgresql development headers, and cabal build (well, stack build) failed with

setup: The pkg-config package 'libpq' version >=9.3 is required but it could
not be found.

instead of failing with something-something pg_config something as expected.

Looks like the absence of a pkgconfig dependency is a hard fail for Cabal (of version 2.4.0.0, that is). Is it intended behavior?

[phadej]

@develop could you run cabal v2-build -v2, and what version of cabal --version do you use?

There's a

showFR _ (MissingPkgconfigPackage pn vr)  = " (conflict: pkg-config package " ++ prettyShow pn ++ prettyShow vr ++ ", not found in the pkg-config database)"

in cabal-install code, so i'd expect it could backtrack (and we'll need to figure out why it doesn't)

[phadej]

E.g. my (development) version of cabal-install seems to try different flag options:

cabal-version: 2.4
name: example
version: 0

flag pkg-config
  manual: False
  default: True


library
  default-language: Haskell2010

  if flag(pkg-config)
    pkgconfig-depends: somethingnotexisting
  else
    pkgconfig-depends: somethingelse

% cabal new-build    
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: example-0 (user goal)
[__1] rejecting: example:+pkg-config (conflict: pkg-config package
somethingnotexisting-any, not found in the pkg-config database)
[__1] rejecting: example:-pkg-config (conflict: pkg-config package
somethingelse-any, not found in the pkg-config database)
[__1] fail (backjumping, conflict set: example, example:pkg-config)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: example, example:pkg-config

(and if other branch doesn't have pkgconfig-depends, it's picked up).

[develop7]

what version of cabal --version do you use?

develop7@t-rex ~/p/h/postgresql-libpq (feature-use-pkg-config) [1]>  stack exec -- cabal --version
cabal-install version 2.4.0.0
compiled using version 2.4.0.1 of the Cabal library 
develop7@t-rex ~/p/h/postgresql-libpq (feature-use-pkg-config)>  cabal --version
cabal-install version 2.4.0.0
compiled using version 2.4.0.1 of the Cabal library 

could you run cabal v2-build -v2

oh, ok, it does fall back after all:

develop7@t-rex ~/p/h/postgresql-libpq (feature-use-pkg-config)>  cabal v2-build
Resolving dependencies...
Build profile: -w ghc-8.6.5 -O1
In order, the following will be built (use -v for more details):
 - hsc2hs-0.68.4 (exe:hsc2hs) (requires build)
 - postgresql-libpq-0.9.4.2 (lib:postgresql-libpq) (first run)
Starting     hsc2hs-0.68.4 (exe:hsc2hs)
Building     hsc2hs-0.68.4 (exe:hsc2hs)
Installing   hsc2hs-0.68.4 (exe:hsc2hs)
Completed    hsc2hs-0.68.4 (exe:hsc2hs)
[1 of 1] Compiling Main             ( /home/develop7/projects/haskell/postgresql-libpq/dist-newstyle/build/x86_64-linux/ghc-8.6.5/postgresql-libpq-0.9.4.2/setup/setup.hs, /home/develop7/projects/haskell/postgresql-libpq/dist-newstyle/build/x86_64-linux/ghc-8.6.5/postgresql-libpq-0.9.4.2/setup/Main.o )
Linking /home/develop7/projects/haskell/postgresql-libpq/dist-newstyle/build/x86_64-linux/ghc-8.6.5/postgresql-libpq-0.9.4.2/setup/setup ...
Configuring postgresql-libpq-0.9.4.2...
setup: The program 'pg_config' is required but it could not be found.
develop7@t-rex ~/p/h/postgresql-libpq (feature-use-pkg-config)>  cabal build
Warning: The build command is a part of the legacy v1 style of cabal usage.

Please switch to using either the new project style and the new-build command
or the legacy v1-build alias as new-style projects will become the default in
the next version of cabal-install. Please file a bug if you cannot replicate a
working v1- use case with the new-style commands.

For more information, see: https://wiki.haskell.org/Cabal/NewBuild

Resolving dependencies...
[1 of 1] Compiling Main             ( dist/setup/setup.hs, dist/setup/Main.o )
Linking ./dist/setup/setup ...
Configuring postgresql-libpq-0.9.4.2...
setup: The program 'pg_config' is required but it could not be found.

So it seems the issue is stack-specific.

[phadej]

Yes, stack doesn't toggle auto-flags by itself (and probably uses the value set in the snapshot).

Ok, good. If toggling works automatically, than these change is very welcome.

[develop7]

Ok, good. If toggling works automatically, than these change is very welcome.

Does it mean we don't need to test it on Windows and the PR is good to merge?

[develop7]

So the requested changes are in, flag probing is covered by cabal and works inherently and on all platforms; is there anything left to fix or the PR is good to merge?

[phadej]

Hmm, I'm still undecided. Having flag automatic feels wrong. The setting should be based on "system has pkg-config or not", not on the fact "system doesn't have pq in pkg-config".

I'm thinking of making use-pkg-config True by default, and let Windows users suffer.

[develop7]

The setting should be based on "system has pkg-config or not", not on the fact "system doesn't have pq in pkg-config".

Not sure whether is it any different from the package maintainer standpoint — either way pkg-config(pq) would resolve to Nothing, amirite?

[phadej]

If there's pkg-config on the system, like Linux, but no pq there, cabal-install should fail immediately and not opportunistically try to compile anyway only to fail with "no pg_config exception".

[develop7]

I can easily imagine the case to not having pkg-config(pq) and have pg_config in $PATH available. Consider EnterpriseDB setup on Windows with "development stuff" checkbox ticked and pkg-config in the same system located elsewhere.

[phadej]

Yes, that's why I'd be happiest to be able to say

flag use-pkg-config
  manual: False
  -- use pg_config on windows, pkg-config on linux
  default: !os(windows)

yet that's not yet possible. I'll see how difficult it's to add to Cabal.

[develop7]

I'll see how difficult it's to add to Cabal.

so this gets postponed to next Cabal release while modern PostgreSQL users would go on hitting this nightstand with their pinkie toes?

[phadej]

FWIW, I'm looking back at this and seems that

Since recent releases of PostgreSQL using pg_config for non-server extensions is discouraged. T

Is something mostly (only?) OpenSUSE implements. For example https://www.postgresql.org/docs/17/libpq-build.html says:

If there is any chance that your program might be compiled by other users then you should not hardcode the directory location like that. Instead, you can run the utility pg_config to find out where the header files are on the local system:
If you have pkg-config installed, you can run instead:

pg_config is mentioned first.

I fail to find anything else even slightly actively discouraging using pg_config.

[develop7]

Agreed, let's stick with the upstream guidelines. Thank you for looking into it.