From Christopher Wellons to ~skeeto/public-inbox
Good thinking, thanks! Accepted and pushed.
From Christopher Wellons to ~skeeto/public-inbox
> pkgconf also has --dump-personality
I didn't know about this, thanks!
From Christopher Wellons to ~skeeto/public-inbox
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
From Christopher Wellons to ~skeeto/public-inbox
> 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
From Christopher Wellons to ~skeeto/public-inbox
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.
From Christopher Wellons to ~skeeto/public-inbox
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
From Christopher Wellons to ~skeeto/public-inbox
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
From Christopher Wellons to ~skeeto/public-inbox
> 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
From Christopher Wellons to ~skeeto/public-inbox
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.
From Christopher Wellons to ~skeeto/public-inbox
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.