pkgconf

Table of Contents

Overall goals

Resolve any remaining legacy pkg-config compatibility issues
Advocacy with distributions

Current state of pkgconf in distributions

Longer-term goals (in order)

libpkgconf library (in progress as of pkgconf 1.0 series)
Toolchain direct integration
Framework discovery for IDEs (if you use such things)
Framework discovery for package managers
Plugin support
Better .pc file creation

Overall goals

Resolve any remaining legacy `pkg-config` compatibility issues

Find and support any remaining pkg-config extensions that are actually used by build infrastructure. The best way of accomplishing this is by running mass tinderbox builds until we have no regressions against pkg-config itself.

Some things should be fixed in pkgconf, other things should be fixed in the upstream sources because they do stupid things they shouldn't be doing, like pkg-config --version to query the pkg-config API level.

Several people are helping with this, such as flameeyes (Gentoo) and bapt (FreeBSD).

Any incompatibility on UNIX platform is a regression and should be considered a bug.

Advocacy with distributions

In order to succeed with our longer-term goals, we need distributions to actually switch their pkg-config implementation in the stack. Once that is done, we can incrementally work on future goals.

Some points for distributions to consider are:

Permissively licensed
Reduced circular dependencies in the toolchain stack.
Support for features distributions need which are unavailable in pkg-config.
Strong test-driven development including strong testing against prior regressions.
Responsive development team that responds quickly to distribution issues. For example, emergency problems in distributions or build environments could be reported to #pkgconf on irc.freenode.net and mitigated in real time.

Current state of pkgconf in distributions

FreeBSD - pkgconf has replaced pkg-config entirely. There is no more pkg-config in tree.
Alpine - pkgconf has replaced pkg-config entirely.
Gentoo - In portage tree ( http://packages.gentoo.org/package/dev-util/pkgconf ), currently available as an alternative to fd.o pkg-config
Funtoo - Replaced pkg-config entirely.
ArchLinux - pkgconf has replaced pkg-config entirely. There is no more pkg-config available, even in the AUR.
Sabotage - fully replacing pkg-config.
pkgsrc default provider for pkg-config functionality. his bring pkgconf available to all platforms supported by pkgsrc (including NetBSD and Dragonfly)
OpenMandriva - fully replaced pkg-config in OpenMandriva Lx 4
Fedora - pkgconf replaced pkg-config entirely in Fedora 26. There is no more pkg-config in F26+.
Mageia - pkgconf fully replaced pkg-config in Mageia 7.
openSUSE - pkgconf fully replaced pkg-config in Tumbleweed, will replace pkg-config in next major Leap release.
Debian - pkgconf package available as an alternative to fd.o pkg-config
Ubuntu - pkgconf package available in universe as an alternative to fd.o pkg-config

Longer-term goals (in order)

libpkgconf library (in progress as of pkgconf 1.0 series)

Allow other frontends to the pkg-config data, this is a critical component for future plans.

Toolchain direct integration

An initial step is to eventually add a -framework option to GCC or Clang (well, really both in reality), so that instead of having a bunch of CFLAGS on the compiler commandline, we can have:

$ gcc -o mygtkapp mygtkapp.c -framework gtk+-3.0

To build a GTK app.

The next steps are obvious, define dependencies in the source and object units themselves. Managed C++ has the using keyword for this. Imagine the following C code:

#using "gtk+-3.0";

GtkWidget *window;

int main(int argc, const char *argv[])
{
    gtk_init(&argc, &argv);
    ...;
}

Wouldn't it be great? I think it would be.

So, essentially, what pkgconf is about is making our toolchain not suck, so we can have code that is more direct and to the point.

Framework discovery for IDEs (if you use such things)

Imagine if you could just add some framework's features by checking a box in Anjuta or whatever. With libpkgconf, it can be possible.

Framework discovery for package managers

The data that pkgconf can provide may be useful to package managers and build systems.

Plugin support

Another planned feature of pkgconf and libpkgconf is the ability to extend it's functionality with plugins.

Plugins will be able to preprocess pkgconf_fragment_t entries, for example to filter them out (further overlinking optimizations) based on analyzing the libraries with libelf or similar.

Better .pc file creation

Finally, we want to provide tools for automatically building .pc files. A tool named something like pcscan could be written to analyze libraries for their dependencies building a .pc file with the correct Libs and Requires.private parameters. This would be cleaner than the current approach (autoconf/cmake templates) and allow for even better optimizations in the future.