Description
Describe the bug
Cabal has for a long time supported discovering native library dependencies through pkgconfig-depends
. This is extremely useful as:
- it can be used by some distributions to transparently provide native dependencies to
cabal-install
(e.g. see nix-pkgconfig) - it makes Cabal packages more robust against non-traditional packaging decisions
- it eliminates the need for Cabal to guess whether the target platform has a particular library
However, due to the fact that pkg-config
is not available by default on some platforms, libraries tend to either not use pkgconfig-depends
(e.g. see regex-posix
) or guard it behind a default-off flag (e.g. see zlib
). This severely cripples the usefulness of the mechanism.
Even worse, the tendency for packages to assume library non-availability on Windows can blow up catastrophically in some cases. This was the case in GHC #19945 where an ABI mismatch triggered by the assumption that Windows environments do not offer a POSIX regex implementation caused an innocuous-looking program to segfault, requiring many hours of debugging.
Proposed design
Users avoid using pkgconfig-depends
by default because it can cause builds to fail when pkg-config
is not available. I suggest one of the following (roughly in order of decreasing desirability):
cabal-install
learn to backtrack if apkg-config
probe fails due to the executable not being availablecabal-install
implement support for setting/clearing thepkgconfig
flag on its own depending upon whether thepkg-config
executable is available, sanctioning the current flag-based conventioncabal-install
assume that thepkgconfig-depends
are available in the event thatpkg-config
is not available