#pkgconf — Public Fediverse posts

#pkgconf 3.0.5 is now released and in Alpine edge.

it largely features correctness fixes and performance improvements.

#pkgconf 3.0.5 is now released and in Alpine edge.

it largely features correctness fixes and performance improvements.

#pkgconf 3.0.5 release is imminent

#pkgconf 3.0.5 release is imminent

does someone want to make a logo for #pkgconf? I hear all the cool new hip projects have logos.

does someone want to make a logo for #pkgconf? I hear all the cool new hip projects have logos.

i just found a really stupid #pkgconf performance bug -- tracing is always enabled and just sending to /dev/null unless --debug is requested.

by properly setting the tracing handler to NULL, we observe a 2.93x performance improvement!

https://github.com/pkgconf/pkgconf/commit/dfd84e24cde5d01f7556d4a94eec1348d5dc57d2

i just found a really stupid #pkgconf performance bug -- tracing is always enabled and just sending to /dev/null unless --debug is requested.

by properly setting the tracing handler to NULL, we observe a 2.93x performance improvement!

https://github.com/pkgconf/pkgconf/commit/dfd84e24cde5d01f7556d4a94eec1348d5dc57d2

#pkgconf 3.0.4 is out which mainly addresses some sysroot and windows path handling regressions.

#pkgconf 3.0.4 is out which mainly addresses some sysroot and windows path handling regressions.

#pkgconf 3.0.3 has been fixed, restoring PKG_CONFIG_FDO_SYSROOT_RULES=1, which broke when i rewrote the entire variable expansion code due to a lack of regression tests.

#pkgconf 3.0.3 has been fixed, restoring PKG_CONFIG_FDO_SYSROOT_RULES=1, which broke when i rewrote the entire variable expansion code due to a lack of regression tests.

#pkgconf 3.0.2 has been released to address building on Solaris

#pkgconf 3.0.2 has been released to address building on Solaris

#pkgconf 3.0.1 is out, no functional change other than including some missing windows-specific files in the tarballs that weren't caught by CI :)

#pkgconf 3.0.1 is out, no functional change other than including some missing windows-specific files in the tarballs that weren't caught by CI :)

#pkgconf 3.0.0 has been released

#pkgconf 3.0.0 has been released

to make #pkgconf work better for CMake users, i am having @Elizafox write a macro package that covers querying pkgconf for data as well as generating high quality pc(5) files for CMake targets.

the reason this hasn't happened before now is quite simple, nobody asked us to provide an official macro package.

to make #pkgconf work better for CMake users, i am having @Elizafox write a macro package that covers querying pkgconf for data as well as generating high quality pc(5) files for CMake targets.

the reason this hasn't happened before now is quite simple, nobody asked us to provide an official macro package.

#pkgconf 2.9.96 has been released.

It is the last expected RC before 3.0 release.

#pkgconf 2.9.96 has been released.

It is the last expected RC before 3.0 release.

#pkgconf 2.9.91 and 2.9.92 added an OOM fault injection test suite that was not compatible with older libc versions due to its dependency on reallocarray

2.9.93 checks to make sure reallocarray is available before building the OOM fault injection tests :)

#pkgconf 2.9.91 and 2.9.92 added an OOM fault injection test suite that was not compatible with older libc versions due to its dependency on reallocarray

2.9.93 checks to make sure reallocarray is available before building the OOM fault injection tests :)

#pkgconf 2.9.92 (3.0 release candidate 3) has been released.

tarballs and windows MSI packages are available on distfiles.ariadne.space

#pkgconf 2.9.92 (3.0 release candidate 3) has been released.

tarballs and windows MSI packages are available on distfiles.ariadne.space

#pkgconf 2.9.90 has been released, mostly to test the release machinery since I've moved to a new colo box.

assuming there are no regressions, pkgconf 3.0 will be released in a few days. please test.

tarball (gz): https://distfiles.ariadne.space/pkgconf/pkgconf-2.9.90.tar.gz
tarball (xz): https://distfiles.ariadne.space/pkgconf/pkgconf-2.9.90.tar.xz

the new release includes windows binaries that are compatible with windows 7 or later (windows 8.1 on ARM).

windows x86: https://distfiles.ariadne.space/pkgconf/pkgconf-x86-2.9.90.msi
windows x64: https://distfiles.ariadne.space/pkgconf/pkgconf-x64-2.9.90.msi
windows arm64: https://distfiles.ariadne.space/pkgconf/pkgconf-arm64-2.9.90.msi

#pkgconf 2.9.90 has been released, mostly to test the release machinery since I've moved to a new colo box.

assuming there are no regressions, pkgconf 3.0 will be released in a few days. please test.

tarball (gz): https://distfiles.ariadne.space/pkgconf/pkgconf-2.9.90.tar.gz
tarball (xz): https://distfiles.ariadne.space/pkgconf/pkgconf-2.9.90.tar.xz

the new release includes windows binaries that are compatible with windows 7 or later (windows 8.1 on ARM).

windows x86: https://distfiles.ariadne.space/pkgconf/pkgconf-x86-2.9.90.msi
windows x64: https://distfiles.ariadne.space/pkgconf/pkgconf-x64-2.9.90.msi
windows arm64: https://distfiles.ariadne.space/pkgconf/pkgconf-arm64-2.9.90.msi

latest #pkgconf 3.0 enhancement: the link.abi tag

different libraries are built with different programming languages, for example, one library might be C, while another might be C++ and another might be fortran. these languages have different ABIs and linking requirements.

how do we know how to link the final program in these cases?

in the past, you had to figure it out by hand and hardcode it in your build system.

now... you can do pkgconf --link-abi <modules> and get an output like:

$ ./pkgconf --link-abi --with-path=tests/lib1 foo link-abi-multi
c c++ fortran

this tells the build system what ABIs it is dealing with, although how it should deal with them remains up to the build system.

please add link.abi tags to your C++ and fortran modules, it is backwards compatible :)

latest #pkgconf 3.0 enhancement: the link.abi tag

different libraries are built with different programming languages, for example, one library might be C, while another might be C++ and another might be fortran. these languages have different ABIs and linking requirements.

how do we know how to link the final program in these cases?

in the past, you had to figure it out by hand and hardcode it in your build system.

now... you can do pkgconf --link-abi <modules> and get an output like:

$ ./pkgconf --link-abi --with-path=tests/lib1 foo link-abi-multi
c c++ fortran

this tells the build system what ABIs it is dealing with, although how it should deal with them remains up to the build system.

please add link.abi tags to your C++ and fortran modules, it is backwards compatible :)

working through the rest of the claude mythos #pkgconf 'findings'

some of these are pretty meh 🙃

working through the rest of the claude mythos #pkgconf 'findings'

some of these are pretty meh 🙃

#pkgconf 3 will ship with a fairly exhaustive libpkgconf testsuite written by @Elizafox, this is on top of our declarative tests which were ported from kyua.

thanks to quansight labs for giving us a grant to work on this and SBOM support in pkgconf :)

#pkgconf 3 will ship with a fairly exhaustive libpkgconf testsuite written by @Elizafox, this is on top of our declarative tests which were ported from kyua.

thanks to quansight labs for giving us a grant to work on this and SBOM support in pkgconf :)

@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.

@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.

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

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?)

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

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

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!

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

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 :)

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.

#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 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?

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?