Is it intended that pkg-config be a prerequisite to use Stackage with Stack?

[mpilgrem]

According to Hackage, over 7,700 Haskell packages depend on zlib-0.7.0.0. So, it seems to me that its non-Haskell dependencies have practical consequences. Unlike earlier versions of the package, by default, zlib-0.7.0.0 requires the executable pkg-config to be on the PATH to be built with Stack (it can, however, be built with --flag zlib:-pkg-config). pkg-config is not provided by MSYS2 on Windows 'out of the box' and I understand from @Bodigrim that it is also not included with all Linux distributions 'by default' (EDIT: I think Alpine Linux is one example). EDIT2: I think that macOS also does not include pkg-config by default and (EDIT3) it is not a tool included in the Xcode Command Line Tools.

Is it intended that pkg-config be a de facto prerequisite to use Stackage package sets with Stack? If 'yes', should that be documented? If 'no', should zlib-0.7.0.0 only be included in package sets if its pkg-config Cabal flag is specified as false?

[Bodigrim]

I understand from @Bodigrim that it is also not included with all Linux distributions 'by default' (EDIT: I think Alpine Linux is one example).

Prettty much no distro includes it by default. E. g., for Ubuntu

wget https://releases.ubuntu.com/jammy/ubuntu-22.04.4-desktop-amd64.manifest -q -O - | grep pkg-config

is empty

EDIT2: I think that macOS also does not include pkg-config by default.

Correct.

---

As a maintainer of zlib, I recommend Stackage to disable its pkg-config flag in build-constraints.yaml.

[ysangkok]

it is also not included with all Linux distributions

Prettty much no distro includes it by default.

Why does it matter what Linux distributions include by default? They don't even ship a C compiler per default.

I would posit that pkg-config is effectively standard on Linux, since if you install headers for an arbitrary library, that package is likely to include a pkg-config configuration.

For example, on Debian 11 if I do dpkg -L zlib1g-dev, I see that it contains /usr/lib/x86_64-linux-gnu/pkgconfig/zlib.pc, but it doesn't include a cmake configuration file.

I do have many results for cmake configuration files, if I search using find /usr/lib -iname '*.cmake'. But it's much less common. I see results for e.g. PulseAudio, harfbuzz, rocksdb, libavif, SDL2, expat and Qt6. Running dpkg -L libexpat1-dev you can verify that this package provides both cmake and pkg-config configuration files.

[alaendle]

Maybe I didn't understand the implications of the two ecosystems, but why should the default behaviour for stack be different? Can't that be confusing? I still not understand why using the system library makes sense for the pure package, but not if used in conjunction with stack.

[mpilgrem]

@ysangkok, I think it (pkg-config on the PATH 'by default') matters in this sense: if Stackage assumes that pkg-config is on the PATH then the Stack project will want to do what it can to ensure that assumption is a good one. It is helpful to know what operating systems and Linux distributions are affected.

[mpilgrem]

The proximate cause of my raising this issue (the zlib package (a) specifying pkg-config on the PATH 'by default' and (b) being included in a package set with that default) has fallen away:

• Re #7387: turn off pkg-config flag for zlib #7388.

However, I think the question asked is still relevant as a matter of principle.

[mpilgrem]

Although I mention Windows/MSYS2 above, if pkg-config were a prerequisite it seems to me that the most problematic operating system would be macOS. That is because it does not have a native package manager. If a macOS user tries to use a tool included in the Xcode Command Line Tools set and the tool is not available, macOS will suggest to the user that Xcode Command Line Tools are installed. However, that set of tools does not include pkg-config.