Make clear when pkg-config is not present

[jasagredo]

When no pkg-config program was found, cabal would claim that the package is not in the db, instead of telling clearly that no pkg-config was found at all.

QA Notes

On a system which has no pkg-config, with this package (for example):

cabal-version:      3.0
name:               aaaaa
version:            0.1.0.0
build-type:         Simple
library
    pkgconfig-depends: zlib
    hs-source-dirs:   src
    default-language: Haskell2010

The following message will be shown:

$ cabal build
Resolving dependencies...
Error: [Cabal-7107]
Could not resolve dependencies:
[__0] next goal: aaaaa (user goal)
[__0] rejecting: bb-0.1.0.0 (pkg-config package zlib-any is needed but no pkg-config executable was found or querying it failed)
[__0] fail (backjumping, conflict set: aaaaa)
After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: aaaaa

In verbose mode, the following warning will also be printed:

$ cabal build -v
Warning: Failed to query pkg-config, Cabal will backtrack if a package from
pkg-config is requested. Error message: cannot find pkg-config program

To emulate this one can do the following invocation that temporarily renames pkg-config executable:

mv $(which pkg-config) "$(dirname $(which pkg-config))/pkg-config-bak"
cabal build -v
mv $(which pkg-config-bak) "$(dirname $(which pkg-config-bak))/pkg-config"

---

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

[Kleidukos]

Oh god I had this exact problem happen recently. Thank you so much!

[Kleidukos]

LGTM. Could you please add some QA notes? :)

[jasagredo]

Sure! QA and changelog will come as soon as I have some time to write them.

Thanks!

[andreabedini]

It looks like the messaging is inconsistent. Apparently the solver used to ignore pkg-config dependencies when pkg-config is missing (which is what this message says) but in 68e2737 the behaviour was changed to backtrack.

Do we need to reconsider this? Is backtracking (and likely failing) without pkg-config the right thing to do? Maybe we could instead make sure Cabal has the same behaviour? (that is, to ignore pkg-config dependencies if pkg-config is missing)

[andreabedini]

In terms of implementation, I'd prefer to change the call site (validateTree).

The value I see in the pkgConfigPkgIsPresent function is to merge the NoPkgConfig case into False, but if we want to keep them separate, we should propagate the change up:

We turn functions producing PkgConfigDb into producing Maybe PkgConfigDb where

newtype PkgConfigDb = PkgConfigDb (M.Map PkgconfigName (Maybe 

Other than changing few types, only code changes I found are in two places:

• Distribution.Solver.Modular.Validate.validateTree which is perfect because it's were you want to deal with the absence of pkg-config.
• Distribution.Client.ProjectPlanning.elaborateInstallPlan which is a bit surprising but good that we found it! 😂

WDYT?

[jasagredo]

It looks like the messaging is inconsistent. Apparently the solver used to ignore pkg-config dependencies when pkg-config is missing (which is what this message says) but in 68e2737 the behaviour was changed to backtrack.

Do we need to reconsider this? Is backtracking (and likely failing) without pkg-config the right thing to do? Maybe we could instead make sure Cabal has the same behaviour? (that is, to ignore pkg-config dependencies if pkg-config is missing)

Perhaps that is something to consider. The very least I want to do with this PR is to clarify the error message on the current logic, a follow-up PR could deal with whether or not the current behaviour is the wanted one.

[Bodigrim]

Apparently the solver used to ignore pkg-config dependencies when pkg-config is missing (which is what this message says) but in 68e2737 the behaviour was changed to backtrack.

Do we need to reconsider this? Is backtracking (and likely failing) without pkg-config the right thing to do?

Yes, backtracking is a right thing to do and it is a crucial ingredient in multiple packages (e. g., zlib). Please do not break this behaviour. This allows packages to enable pkg-config flag by default so that platforms with pkg-config benefit from relying system packages (less to build, more secure), but platforms without easily available pkg-config (think Windows or thing JavaScript) do not degrade in user experience.

[andreabedini]

Yes, backtracking is a right thing to do and it is a crucial ingredient in multiple packages (e. g., zlib). Please do not break this behaviour. This allows packages to enable pkg-config flag by default so that platforms with pkg-config benefit from relying system packages (less to build, more secure), but platforms without easily available pkg-config (think Windows or thing JavaScript) do not degrade in user experience.

I had no intention to change that behaviour. You make a good argument. In this case we should make sure the behaviour (and its reason) is documented and that the code is consistent with it.

[jasagredo]

@andreabedini I unified your branch and mine into this one, and fixed some compilation errors plus some rewording on the error message. Let me know how it looks 👍

[andreabedini]

Note that, in readPkgConfigDb, we use ioErrorHandler to call noPkgConfig in case something fails.

So if pkg-config is available but calling it fails for some reason, we will still return Nothing and backtrack on all pkg-config constraints. This possibiliy is mentioned in the comment right above.

Do we need to worry about this? Recent experience showed that querying pkg-config can be unreliable (see #8930, #9134, #9360, #9478, and my own #9422, ping @georgefst).

Ping @Mikolaj @Kleidukos @ulysses4ever @Bodigrim @georgefst

@jasagredo beside updating that message above, the implementation looks good to me now 👍.

[Kleidukos]

So if pkg-config is available but calling it fails for some reason, we will still return Nothing and backtrack on all pkg-config constraints.

Ah, indeed the loss of granularity is problematic. That being said I am not knowledgeable enough to assert that calling pkg-config twice will produce a reliable result (reliably failed or unreliably succeeded on the second time).

[andreabedini]

👍

[sebright]

Thanks for simplifying PkgConfigDb, too!

[jasagredo]

@grayjay I think both of your comments are very valid points. I will incorporate them, then merge. Thanks!

[jasagredo]

Rebased on latest master