Great article and also great software! I've been using pkgconf since
that's what my system default was and it's description says
| pkg-config compatible replacement with no dependencies other than ANSI C89
so I never bothered looking into it - up until a week ago prompted by
your email re: sdl3-config. Just taking a glance at the git repo and I
immediately knew what the problem was.
It's unfortunate that so many developers will put effort into minimizing
run-time dependencies (which is commendable) but forget that:
1. On order for a software to run, it first has to be built.
2. Not everyone is using a binary distribution.
3. Users may still want to build the software from source for various
reason even if they were using a binary distribution.
And thus they end up neglecting their build time dependencies entirely.
I also hadn't known about pkgconf's memory corruptions issues, but as
you noted, the usage of `strlcpy` and the memory corruptions aren't an
accident. It's a sign of missing the forest because of staring at the
This does give me some motivation to try and replace pkgconf with
u-config on my system when I have some time and am feeling adventurous.
I'll make sure to report back if I do get around doing so.
For "temp arena" I tend to use the following construct:
AllocCtx checkpoint = memctx;
// use memctx
memctx = checkpoint;
It never occurred to me that the "restore checkpoint" can be done
automagically by leveraging C's block scope lifetimes. SUPER NEAT!
I know it's a really small thing, but I liked it a lot!
Also one typi on the post:
- sizes and subscripts should be typed.
+ sizes and subscripts should be signed.
And you might also want to consider adding the "lib64" into the default
search path as well (which is what my system uses):
PKG_CONFIG_PREFIX "/local/lib/pkgconfig" PATHDELIM
+ PKG_CONFIG_PREFIX "/local/lib64/pkgconfig" PATHDELIM
PKG_CONFIG_PREFIX "/local/share/pkgconfig" PATHDELIM
PKG_CONFIG_PREFIX "/lib/pkgconfig" PATHDELIM
+ PKG_CONFIG_PREFIX "/lib64/pkgconfig" PATHDELIM
I'm glad you like it, NRK!
> neglecting their build time dependencies entirely
Agreed. It's my primary objection to Meson: it makes Python a transitive
build dependency. In theory muon solves this, but it's stricter and does
not actually work with most Meson builds. Case in point: pkgconf currently
cannot be built with muon.
> I'll make sure to report back if I do get around doing so.
I'm interested in hearing how it goes! When choosing which features to
implement, I've been guessing about which matter in practice.
> the "restore checkpoint" can be done automagically
I was doing the same for awhile, then I noticed could skip a step by using
the "checkpoint" instead of the original. In the end I didn't keep any
instances, but mid-way through I had a few cases where I passed the arena
itself instead of an arena pointer. Then the callee couldn't retain any
allocations, having only the copy to work from.
> Also one typi on the post:
> And you might also want to consider adding the "lib64" into the default
Well, unless it's a 32-bit host, right? :-) So at the very least I'd need
to detect 32-bit vs. 64-bit. Aside from choosing a path delimiter, I've
deliberately avoided detecting host configuration. Even if I did, such
detection would be insufficient. If u-config was built as a cross-compile
tool, then u-config might itself be 64-bit while the "target" is 32-bit.
Further, my Debian system doesn't include lib64, and instead uses the
architecture triple. In fact, I have a bunch of pkg-config binaries
prefixed by an architecture triple, which I believe are intended as
cross-compile tools. However, looking more closely, none are configured
properly for their role. My i686-linux-gnu-pkg-config searches under
x86_64-linux-gnu. I guess nobody's noticed. (When I look too closely at
any software, I'm amazing anything actually works!)
As noted in the README, the default path really must be specialized to the
distribution since everyone does things a little differently. That's why I
stuck to the bland default search path straight from the pkg-config
documentation. The pkg-config I'll distribute with w64devkit will itself
be customized for w64devkit since it will live just outside the sysroot in
the top level bin/.
For something more automatic, take a look at the "pkg-config" target in
the Makefile. It extracts the default path from your current pkg-config
for its own default, so you'll get a u-config tuned to your system. If all
works as planned, you could then uninstall pkg-config and drop u-config in
On Wed, Jan 18, 2023 at 11:00:47AM -0500, Christopher Wellons wrote:
> When I look too closely at any software, I'm amazing anything actually works!
Reminds me of an IRC log a friend once shared with me (coincidentally,
it's also about build systems!). It's from 2019 on the K1SS linux room
(reformatted a bit for readability):
18:15 <dylanara1> Firefox currently depends on a 15~ year old version of `autoconf` to build btw.
18:21 <dredrim> I guess those are the kinds of horror stories you see when making a package manager.
18:22 <dylanara1> I could go on for days.
18:22 <dylanara1> Making KISS convinced me that nothing should work.
18:23 <dylanara1> "autoconf-2.13.tar.gz 1999-01-15 16:03 433K"
18:23 <dylanara1> I was wrong, it's older.