don't do clever things in configure scripts

Recently, a new version of ncurses was released and pushed to Alpine. The maintainer of ncurses in Alpine successfully built it on his machine, so he pushed it to the builders, expecting it to build fine on them. Of course, it promptly failed to build from source on the builders, because make install did not install the pkg-config .pc files to the right location.

You might think, what a weird regression, and you’d be right. After all, pkg-config files are usually just installed to $libdir/pkgconfig in any sort of autotools-based build system. Indeed, in the past, this is what ncurses did as well. However, this was clearly too robust of a solution to the problem of determining where to install the pkg-config files, and so innovation™️ happened:

Yes, you are reading this right: it is scraping debug output to find the pkg-config search path. This kind of behavior is clever, and it should absolutely be avoided in anything designed to be portable, such as a configure script. In fact, really, a build system should follow established expectations, specifically, in the autotools case, it should just default to $libdir/pkgconfig and allow the end user to override that if it makes sense to. Doing anything else is going to lead to edge cases and problems, since it is more clever than the user expects it to be.

the portable way to query the search list

If you really need to query the pkg-config search list, use pkg-config --variable=pc_path pkg-config. It is supported by every implementation of pkg-config, and it is an interface we all agreed to support explicitly for this use case. This method is supported by’s implementation, OpenBSD’s implementation and pkgconf, which are the three main implementations in production use.

There is absolutely no need to scrape debug output, which is absolutely subject to change and should never be considered a stable interface in any program.