search

NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
18.39k stars 14.34k forks source link

Use pkgconf as our pkg-config implementation #334195

Open emilazy opened 3 months ago

emilazy commented 3 months ago

The original freedesktop pkg-config implementation we use is pretty dead (no stable release since 2017, no commits in 3 years, no code changes since 2019), and has a variety of issues, including an awkward circular GLib dependency that makes bootstrapping more annoying, and missing support for useful .pc features.

pkgconf is a compatible from‐scratch reimplementation that avoids all these issues; they have a (biased, naturally, but still) comparison to pkg-config. Fedora has already moved to pkgconf as its pkg-config implementation, as have Arch, Alpine, and Debian.

@reckenrode will be using pkgconf in the Darwin SDK rework because of build issues with pkg-config’s vendored GLib, so the problems here are not just theoretical. I think we should strongly consider moving wholesale to pkgconf.

reckenrode commented 3 months ago

@reckenrode will be using pkgconf in the Darwin SDK rework because of build issues with pkg-config’s vendored GLib, so the problems here are not just theoretical. I think we should strongly consider moving wholesale to pkgconf.

One thing I’d like to clarify is that it’s used only in the bootstrap. The final package set will have whatever pkg-config implementation is used by default in nixpkgs.

The problem for Darwin is that pkg-config bundles its own glib, which fails to build in the new bootstrap because it needs arpa/nameser.h, which is provided by libresolv, which is built with Meson, which depends on pkg-config. I need to break the chain of circular dependencies somewhere, which I did by making pkgconf the top-level pkg-config in the bootstrap.

(For those who are not aware, it’s such a hassle dealing with xcbuild to build source release packages that it’s easier/faster to reimplement their build systems using Meson. I chose Meson because it is easy to use and readable.)

emilazy commented 3 months ago

Right, I didn’t mean to imply that we’re getting a platform split on this, just to point to an example of how our existing pkg-config implementation is actively worse for us in practice such that we resort to pkgconf anyway. pkg-config’s bootstrapping issues are well‐known in other distros and a big motivator for why the ecosystem has largely moved over to pkgconf.

reckenrode commented 3 months ago

Sure, sorry if I came across like you were. I wanted to address those less familiar with what’s in the plans for Darwin in case someone got an incorrect impression about it.

RossComputerGuy commented 3 months ago

@reckenrode will be using pkgconf in the Darwin SDK rework because of build issues with pkg-config’s vendored GLib

I'm looking to have an LLVM based bootstrap in the future possibly and from the looks of it, we might run into the same exact problem as Darwin because of this problem. Using pkgconfig instead of pkg-config sounds great.

emilazy commented 3 months ago

Working on this.

theoparis commented 1 month ago

I would also like to see this happen. I noticed that the pkgconf derivation doesn't have the pkg-config binary at the moment.

emilazy commented 1 month ago

I'm focusing on 24.11 stuff right now with the release being imminent, but I'd definitely like to try and make this happen for 25.05.

tobim commented 1 month ago

There is an important difference between the two in nixpkgs tho: pkg-config is patched to ignore Requires.private for --cflags without --static, whereas libpkgconf is not. I believe such a change also has to be made for pkgconf to be viable.

emilazy commented 1 month ago

That patch is bad and has caused us problems. Avoiding it would be one of the benefits of switching we discussed when running into issues with wlroots recently because of it. We would have to either propagate more packages or (preferably) figure out a way to have absolute paths to private .pc dependencies.