Hmm, not quite sure how we should approach the .pc files shipped with winlib builds.

• libraries already building .pc files might cause issues with pkg-config variants/versions which always verify Requires.private (Prepend brew's pkgconfig to PKG_CONFIG_PATH #16741 (comment) ff)
• it might not be worth doing proper .pc files for libraries not already building .pc files for Windows (spend quite a while on OpenSSL and Net-SNMP the other day)
• PHP completely ignores static builds (i.e. the *.private lines)
• PHP (i.e. PHP_EVAL_INCLINE and PHP_EVAL_LIBLINE) completely ignores anything but -I, -L and -l, and -pthread (might be correct wrt the item above)

So we could just roll out minimalist .pc files for our builds, not even catering to the "canonical" .pc names, and just have a single .pc file per package (i.e. not openssl.pc, libssl.pc and libcrypto.pc for OpenSSL, but only openssl.pc). That would save a lot of work (including rebuilding the packages), but might not be best for interoperability with custom dependency builds (although these may not be interoperable at all, see https://gitlab.freedesktop.org/pkg-config/pkg-config/-/merge_requests/13).

is a nice example why not using something like pkg-config is not the best idea. We're unconditionally requiring OpenSSL, even though Net-SNMP might have been built without OpenSSL support.

Perhaps better examples are ext/ssh2 and ext/curl, which also require OpenSSL, although either libssh2 and libcurl could be built with Schannel support instead.

Or ext/zip, which requires to have liblzma, and sets a couple of defines in the CFLAGS, so makes some strong assumptions about how libzip had been built. Wanting to use these flags from .pc files would be a point pro proper .pc files.

Or ext/zip, which requires to have liblzma, and sets a couple of defines in the CFLAGS, so makes some strong assumptions about how libzip had been built.

Except for /D LZMA_API_STATIC (which might not even be needed), these defines are not something pkg-config (usually) would report. These flags are set whether some functions in the library exists, and these check are hard to replicate with our Windows AC compat layer, so hard-coding makes some sense (albeit these are still strong assumptions). But this is unrelated to this ticket.

Anyhow, I've build libzip as usual, and got the following libzip.pc:

prefix=C:/Program Files/libzip
exec_prefix=${prefix}
bindir=${prefix}/bin
libdir=${prefix}/lib
includedir=${prefix}/include

zipcmp=${bindir}/zipcmp

Name: libzip
Description: library for handling zip archives
Version: 1.11.2
Libs:  -L${libdir} -lzip
Libs.private:  -ladvapi32 -lbz2 -llzma -lbcrypt -lzlib_a
Cflags: -I${includedir}

That is pretty accurate (besides that -lzip won't work since we're calling it libzip_a.lib; likely an insufficient patch of winlibs), but how would PHP (or any other client) know whether to build against a static or shared library (in this case there is no shared library at all)? Note again that PHP ever only calls PKG_CHECK_MODULES (what assumes shared libraries); that might be appropriate for most systems, but on Windows we have quite a couple of static library dependencies. Why? Maybe for BC reasons, maybe for convenience (to avoid shipping many more DLLs which would not easily be found by Webserver modules), and sometimes likely to avoid problems with libraries wich are not fully thread-safe (e.g. Net-SNMP has init and shutdown routines; cf. libxml2; not sure that the commit message is accurate, but multi-threading can indeed be a problem).

So if we want to use pkg-config on Windows (and I still think this is a good idea for the reasons given in the OP), we should just roll our own .pc files. After all, it's not hard to manually craft (and some automation might still be possible) something like:

prefix=C:/usr
libdir=${prefix}/lib
includedir=${prefix}/include

Name: libzip
Description: winlibs' libzip package
Version: 1.11.2
Requires: libbzip2 zlib liblzma
Libs: -L${libdir} -llibzip_a
Cflags: -I${includedir}

Custom dependency builds could copy these and adapt if needed. And downstream consumers other than PHP (if there are any) would likely not be affected, since we've shipped no .pc files so far, so they probably don't use pkg-config at all.

FWIW, my nitpick here is suggesting pkgconf instead of u-config. It's portable and maintained (unlike fdo p-c), and has been around for years so it should be well tested with libraries (unlike u-c).

I don't mind which pkg-config variant we use here. u-config was just trivial to build (CMake), while pkgconf would require Meson (not a big deal, though).

and has been around for years so it should be well tested with libraries

This is likely irrelevant here, because we're probably not using *.pc files built by packages (of the 37 core dependencies, only about 6 already produce *.pc files), and we cannot necessarily use these, because:

Note again that PHP ever only calls PKG_CHECK_MODULES (what assumes shared libraries); that might be appropriate for most systems, but on Windows we have quite a couple of static library dependencies.