#pkgconf — Public Fediverse posts

@danirabbit I am using it to administer a grant to #pkgconf relating to SBOM work. The person doing the work covered by the grant invoices the collective and then I approve it once we come to an agreement for the invoice amount based on the scope of work for each phase.

i have added a #muon build to #pkgconf CI. the goal of this is to allow us to begin thinking about deprecating the autotools-based build system.

this won't happen until next year, most likely, but muon is sufficiently complete at this point that i think it solves the bootstrapping problem enough that we can start thinking about getting rid of the autotools stuff, probably in pkgconf 3.1 or so.

i have added a #muon build to #pkgconf CI. the goal of this is to allow us to begin thinking about deprecating the autotools-based build system.

this won't happen until next year, most likely, but muon is sufficiently complete at this point that i think it solves the bootstrapping problem enough that we can start thinking about getting rid of the autotools stuff, probably in pkgconf 3.1 or so.

i have added a #muon build to #pkgconf CI. the goal of this is to allow us to begin thinking about deprecating the autotools-based build system.

this won't happen until next year, most likely, but muon is sufficiently complete at this point that i think it solves the bootstrapping problem enough that we can start thinking about getting rid of the autotools stuff, probably in pkgconf 3.1 or so.

i have added a #muon build to #pkgconf CI. the goal of this is to allow us to begin thinking about deprecating the autotools-based build system.

this won't happen until next year, most likely, but muon is sufficiently complete at this point that i think it solves the bootstrapping problem enough that we can start thinking about getting rid of the autotools stuff, probably in pkgconf 3.1 or so.

i have added a #muon build to #pkgconf CI. the goal of this is to allow us to begin thinking about deprecating the autotools-based build system.

this won't happen until next year, most likely, but muon is sufficiently complete at this point that i think it solves the bootstrapping problem enough that we can start thinking about getting rid of the autotools stuff, probably in pkgconf 3.1 or so.

anyway #pkgconf users can use X-ESRB-Rating or whatever, I guess. 🙃

would an annual (or perhaps semi-annual) #pkgconf distributions meeting be useful?

(and if you have thoughts, reply here?)

thanks to everyone who tuned in to watch the last little bit of building out the new #pkgconf test harness

tonight i will be refactoring #pkgconf CLI so that we can get rid of the kyua/atf testsuite in favor of a standard TAP testsuite.

i might stream this if i feel like it

i will be doing another #pkgconf dev stream in an hour or so! this one will mostly be about pkgconf on windows platforms, it is finally time to clean up the mess.

this one will be on both youtube & twitch because no 24 hour waiting period this time!

apparently #pkgconf lets you do:

Requires: foo
Requires: bar
Requires: baz

freedesktop pkg-config does not support this, so i have added a lint

i will be talking about #pkgconf at FOSDEM in the SBOM devroom! don't know when it is scheduled yet, though :)

#pkgconf dev stream will be around 8pm PT! there is a little bit of setup i need to do with restreamer first. this is also kind of a test run, i am planning on doing streaming on a regular basis now that i have things mostly set up the way i want.

as a reminder, i will be talking about pkg-config, early/present #pkgconf, and pkgconf 3.x at #SeaGL2025 next saturday (november 8!)

if you care about SDK management, C SBOMs, or software packaging at large, there will be useful content for you! lots of exciting stuff to discuss!

as part of the talk that i am giving about #pkgconf in about a month, i am trying to track the evolution of the pc(5) file format.

for example, in early pkg-config, these were just shell scripts that were somewhat similar to the old gnome-config module concept.

but, while i have pkg-config 0.1.0, i don't have any versions between 0.2.0 and 0.11 (which uses the basic format we are used to today). it would be nice if i could find those versions, so i could demonstrate the capabilities of the shell script version at its peak.

does anyone have them somewhere?

at 2:17 of the new michael mjd video about some XFCE theme, he installs #pkgconf in order to build some software

#pkgconf 2.5.0 is released, with a few new interesting features.

the big one is preloaded packages, which is discussed here: https://social.treehouse.systems/@ariadne/114626642134151151

pkgconf also grew unveil(2) and pledge(2) support on systems that implement these hardening features.

we also cleaned up a lot of minor memory safety issues identified by the GCC 15 static analyzer.

oh, and importantly, this is the first release where the release tarballs are generated and published by CI.

#pkgconf 2.5.0 will be out next week

wrapping up the #pkgconf #landlock topic branch tonight

#pkgconf 2.5.0 release is imminent, bringing significant upgrades to our documentation and major refactoring to start moving beyond legacy pc(5) files, as well as support for OpenBSD unveil(2) and Linux landlock APIs (still need to merge this topic branch).

fairly impressed with GCC 15's -fanalyzer

outside of an unfortunate API design decision that requires us to use -Wno-analyzer-file-leak (maybe I should fix the API since we are bumping SOVERSION anyway), it found a few things to fix in #pkgconf!

fun fact: the distfiles.ariadne.space server which hosts #pkgconf tarballs uses around 5gbps 95th% to serve them to the world

i should probably figure out something like fastly or something

#pkgconf git now has full support for pledge(2) and unveil(2) usage on OpenBSD. I have pointed the OpenBSD folks at the commits they should pull in to their local copy in the base system.

So hopefully OpenBSD's pkgconf-lite (the one in base) will get these changesets soon.

As #OpenBSD begins to adopt #pkgconf, they have been revamping the pkgconf manual.

Questions asked during that process have led us to identify a few corner case bugs in pkgconf that probably don't really matter to anyone in practice.

But we are fixing them anyway.

2026 will mark 15 years of #pkgconf. accordingly, i am planning to give talks about #pkgconf and would love to know where people would like to see such content, e.g. which conferences i should submit proposals to 🙃

#pkgconf 2.4.2 has been cut, it should hopefully fix remaining issues relating to recent refactoring work.

#pkgconf 2.4.1 is out with a minor fix to the solver.

in #pkgconf 2.3 series, we simplified a lot of the code by assuming the solver would always look at a full DAG as its input.

this was mostly fine, except we learned this morning that the solver input was still influenced by the frontend...

#pkgconf 2.4.0 is out with significant improvements to the CLI as well as improved handing of ${pc_sysrootdir} and tracking of fragment groups, which allows pkgconf to understand things like -framework Foo without hacks as well as linker groups (e.g. -Wl,--start-group ... -Wl,--end-group).

feels good to see #pkgconf at the top of today's update set on my thinkpad as part of the next alpine 3.21 milestone!

2011 me didn't know how to write a SAT solver (fabled wrote the one in apk-tools), but i muddled through and figured it out

but by 2024 we have a pretty decent solver in #pkgconf that can solve really complex graphs in a fraction of a second (thanks to @DG0YT for helping out a lot here ❤️)

the point is, anyone can figure anything out if they're willing to just sit down and learn

#pkgconf 2.3.0 has been released with a few patches to fix some version parsing edge cases, as well as an improvement to the solver to color solution nodes that were part of the original query.

in addition, it has the --env=<prefix> flag which works in concert with --cflags, --libs, --print-variables, and --variable=<varname>. this is designed for build systems that want some reusable output without having to do any further processing.

there is also the --exists-cflags addition, which adds -DHAVE_FOO style options for every dependency that was part of the original query that could be located.

also, the PKG_PROG_PKG_CONFIG autoconf macro was given an optional failure path, and the failure to find pkg-config has now been upgraded to a fatal error.

https://distfiles.ariadne.space/pkgconf/pkgconf-2.3.0.tar.xz
SHA2-256: 3a9080ac51d03615e7c1910a0a2a8df08424892b5f13b0628a204d3fcce0ea8b

Trying to wrap my head around the #libtool and #pkgconf vs pkg-config situation. What is going on?
Why is libtool bad, what is wrong with .la files, what does libtool do that pkgconf doesn't, and what does pkg-config do that neither of them do??
If anyone seeing this has dealt/is dealing with this linking/tooling situation I'd love to hear your thoughts :) Very curious.

#programming #freedesktop #autotools #dependencies