pkg-config: split out pkg.m4

[cho-m]

Proof of concept for now to try to align with major repositories and switch from pkg-config to pkgconf.

Fedora's explanation on switch back in Fedora 26: https://fedoraproject.org/wiki/Changes/pkgconf_as_system_pkg-config_implementation

Debian introduced transitional package in Bookworm https://packages.debian.org/bookworm/pkg-config

---

Due to conflict and limited conflict handling, it is a little tricky to change the default in Homebrew (while keeping pkg-config formula as opposed to removing it like Debian/Fedora)

One idea here is to temporarily remove the conflict and then make use of our shims to help out (given we have one on macOS already so cannot directly use PKG_CONFIG environment variable).

[carlocab]

Why not just:

• make pkg-config keg-only
• add pkg-config symlinks to pkgconf
• update the pkg-config shim in brew to look for pkg-config from PATH (e.g. with try_exec_non_system in utils.sh)

?

[cho-m]

Why not just:

• make pkg-config keg-only
• add pkg-config symlinks to pkgconf
• update the pkg-config shim in brew to look for pkg-config from PATH (e.g. with try_exec_non_system in utils.sh)

?

That actually was my first idea (the commented out symlink was what I was planning).

Only wasn't sure about impact on users. If there is no major concern, then may be easier to go that route.

[Bo98]

I've thought about this for a while now.

Homebrew's pkg-config, including the .pc files we ship with brew, are very much critical to some macOS build infrastructure. Swift Package Manager's pkg-config support uses it under the hood. So we ideally don't want to break anything here or otherwise force users to make changes to adjust.

pkgconf's compatibility layer has been heavily tested at this point given it's being used in Debian now (albeit doesn't guarantee bug-level compatibility, though very little things do). Ideally we'd just make pkg-config point to it. This does go against what we've usually do however (e.g. our fork rules). But brew install pkg-config is so widely used that the usual path deprecating it would be incredibly disruptive to the point it seems like that would be the more harmful option. Having the two co-exist but conflict is also horrible UX if one formula declares a dependency on one and one formula declares a dependency on the other.

Whatever we do here, I suspect it won't align with what we "normally" do, in one way or another.

[fxcoudert]

Are there significant bugs in pkg-config that warrant the migration? I mean, it's pretty stable at this point.

[cho-m]

Are there significant bugs in pkg-config that warrant the migration? I mean, it's pretty stable at this point.

My opinion is there are enough advantages of switching, e.g.

1. More complete implementation of pkg-config spec, as noted by Fedora:

   Provides rules and Cflags.private rules are supported, and pkgconf has a better (and less costly) dependency resolver for .pc files

2. Major adoption so it is what most upstream CIs are already running. From glance, default at Alpine, Arch Linux, Debian/Ubuntu, Fedora/RHEL, and NetBSD(pkgsrc). Also seems like recommended standard for Windows so encompasses all other major OS. Main repositories that aren't using it outside of us look like:
   • OpenBSD may be using their own fork of pkg-config - https://man.openbsd.org/pkg-config.1#AUTHORS
   • MacPorts is the same as us using original pkg-config - https://ports.macports.org/port/pkgconfig/details/
3. No bundled glib thus better meets Homebrew/core preferences, faster to compile and smaller in size when installed.
4. For most part, compatible with pkg-config and generally a superset of features - http://pkgconf.org/features.html
5. The stable API/ABI library is a nice bonus
6. Due to current brew conflicts handling, it is harder to install pkgconf

---

The main problem is how to switch.

Some options I see:

1. Implement a more graceful conflict handling (New and improved conflicts_with handling for formulae and casks brew#16398) and shim support. Then we can migrate Homebrew/core usage to pkgconf which will automatically swap out pkg-config unless user manually ran brew install pkg-config.
2. A more aggressive approach of making pkg-config formula as a virtual package for pkgconf and later on make it an alias/rename. Original formula may be added under a separate name.

It sounds like keg-only approach will be bad. Same with this PR approach as we won't be able to handle brew install pkg-config situation if we re-introduce conflicts after migration.

[Bo98]

Are there significant bugs in pkg-config that warrant the migration? I mean, it's pretty stable at this point.

Bug wise: I'm not sure. There is an unfixed upstream compile issue we're already working around (and looks like will remain unfixed upstream) but I'm not an expert on outstanding runtime bugs.

Feature wise there is a difference, e.g. pkg-config doesn't support Cflags.private and Provides whereas pkgconf does. Not anything we've specifically needed ourselves yet though.

There is definitely not an immediate urgent need to switch and I don't think anything will happen before e.g. Sequoia bottling. We are however becoming the minority of those who are sticking around with pkg-config. Arch, Alpine, Debian, Fedora, FreeBSD, Gentoo, Ubuntu and more have all have fully replaced pkg-config with pkgconf now. Nix are working on migrating. At what point do we make the call? Or do we try keep maintaining pkg-config ourselves for as long as possible?

[Bo98]

It sounds like keg-only approach will be bad. Same with this PR approach as we won't be able to handle brew install pkg-config situation if we re-introduce conflicts after migration.

Yeah the one thing we can agree on is that we should not break brew install pkg-config, and keg-only would do that by requiring PATH changes.

This is also why apt install pkg-config is just an alias for apt install pkgconf. Debian etc did not want to maintain pkg-config anymore as upstream weren't and there wasn't any benefits to do so over pkgconf, but they also did not want to break existing use cases so the compatibility layer is there.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[carlocab]

I'd be game to 🗑️ pkg-config and then add a pkg-config symlink to pkgconf.