Open mpilgrem opened 5 months ago
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
.
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.
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.
@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.
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:
However, I think the question asked is still relevant as a matter of principle.
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
.
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 executablepkg-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 includepkg-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', shouldzlib-0.7.0.0
only be included in package sets if itspkg-config
Cabal flag is specified asfalse
?