You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 a pkg-config probe fails due to the executable not being available
cabal-install implement support for setting/clearing the pkgconfig flag on its own depending upon whether the pkg-config executable is available, sanctioning the current flag-based convention
cabal-install assume that the pkgconfig-depends are available in the event that pkg-config is not available
The text was updated successfully, but these errors were encountered:
I think I can have a go at option 1. Would appreciate someone pointing me to the simplest possible package that uses pkgconfig-depends they can think of so I can use it as a test case :-)
(And ideally this would have a cabal file example of how to build it in the no pkg-config case too!)
Describe the bug
Cabal has for a long time supported discovering native library dependencies through
pkgconfig-depends
. This is extremely useful as:cabal-install
(e.g. see nix-pkgconfig)However, due to the fact that
pkg-config
is not available by default on some platforms, libraries tend to either not usepkgconfig-depends
(e.g. seeregex-posix
) or guard it behind a default-off flag (e.g. seezlib
). 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 whenpkg-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 availableThe text was updated successfully, but these errors were encountered: