Good thinking, thanks! Accepted and pushed.

> pkgconf also has --dump-personality

I didn't know about this, thanks!

Thanks for the kind words, biker95!

Sometimes I have considered making videos in addition to writing on a 
topic, since some concepts are just better when seen in action. I just 
never take the time to sort out the details.

> I hope they fix the Wiki for SDL3

Since it's a wiki and an open source project, is that also not in your 
hands as well? :-)

> a little question about the #include "SDL.h" part 

I couldn't find a hard answer about this, and the best source I have is an

> something like this and found `splitpath`

That was one of those functions needing revisiting, and I indeed rewrote 
it yesterday in terms of cut() in order to support --with-path.

> pkgconf pkg-config --variable pc_system_libdirs

I should have realized that since your patch set these! I didn't know you 
were copying a pkgconf-only feature. So unfortunately it won't work if the 
system has pkg-config (i.e. still the default for Debian and derivatives).

The Debian package (in debian/rules) uses dpkg-architecture alongside "gcc 
-print-multi-lib" to construct its system library path, which is hardcoded 
as a string in the binary with no way to access it directly. The include

I forgot to mention: Do you know how to extract pkg-config's embedded 
system include/lib paths? I'd like to do the same as with pc_path, 
automatically configuring from the system's pkg-config. Matching its 
configuration has been useful for testing, but I know of no reliable way 
to get pkg-config to divulge it.

I applied your patch, but with edits:

I didn't like that rem.s overflows in some cases: If dlen == rem.len, then 
"rem.s += dlen + 1" goes too far. I didn't want this to exist in any 
commit, even if immediately fixed, so that's when I decided to edit the 
patch. I first made the cut() default more sensible (b7fafa6) then applied 
it here.

My mindset has been that subscripts and especially manipulating "len" is 
"low level" and that "high level" functions should be preferred since 
they're easier to get right and are guarded by assertions. The needed high 
level functions have been gradually revealed as the program evolves — when 
I notice low level patterns and pull them up. I still need to revisit some 
of the older code and replace low level manipulations with cut() and

I've been testing as well, except building directly from source tarballs, 
which is why I'd added those accept-and-ignore options. The only case I 
have that still doesn't work is Python. That's because the libffi.pc in 
Debian Bullseye has the wrong information. It works with pkg-config and 
pkgconf because they exclude the wrong information by chance, and the 
fallback happens to work out anyway.

Unlike Autotools, portage exercises a lot of pkgconf-only features! I'm 
not running into these in my source tarball tests.

> checking pkg-config is at least version 0.9.0... Aborted

I suspect it's parsing the output of --version instead telling it to check 
itself with --atleast-pkgconfig-version. I noticed that pkgconf --version

> why are you concerned about "where to put it"

The point is that I'm not. As integration between independent tools — 
taking your word at "provides primitives" — it can only by solved by 
distributions providing both intending them to work together. So I leave 
it to packagers to solve appropriately in their distribution, and they'll 
choose a pkg.m4 appropriate for it. A pkg-config shouldn't be concerned 
with pkg.m4 any more than it is with pkg.el, pkg.py, pkg.lua, or other 
integrations. Historically Freedesktop.org pkg-config distributed a 
pkg.m4, which pkgconf copied (literally, and that's not a bad thing), and 
it's why it's still packaged that way. However, it's probably a mistake 
for distributions to reflect this in their package structure today.

Case in point: it's definitely a mistake for Debian and its derivatives. I

Thanks for catching this! Turns out I had misunderstood the interaction 
between Requires.private and --cflags. It should output private cflags 
since these will be necessary for the includes and such to work. Private 
--libs are excluded when dynamic linking to avoid "overlinking," and it 
instead relies on the dependency information already present in dynamic 
libraries.

I've addressed this in 269cbb4, which now outputs these private cflags. I 
needed extra bookkeeping for this, but it's cleaner overall. Since the 
dependency tree is flattened during the load, it may be possible that in a 
deep dependency tree a package is loaded privately, then later needed 
publicly, but it's left private when it should be public, but I was unable 
to contrive a case where this actually happens.

My main complaint is that bootstrapping is necessary in the first place, 
because it's ridiculous and, as demonstrated, easily avoided. It's the top 
listed reason why FreeBSD switched to pkgconf:

https://www.mail-archive.com/freebsd-ports-announce@freebsd.org/msg00018.html

I myself had observed the pkg-config configure script invoking pkg-config 
(configurable via PKG_CONFIG). However, I hadn't realized until just now 
that --with-internal-glib prevents the build from using pkg-config, which 
breaks the loop. So if got the autotools outputs working on busybox-w32, 
the bootstrap wouldn't have been an impediment because I'd be using the 
embedded glib which it can find and use without pkg-config. I've added a 
note about this to the article, so thanks for pointing it out.