Skip to content

PkgConfig: Add PKG_CONFIG_ALWAYS_ADD_TARGET variable

Adam Badura requested to merge adam.f.badura/cmake:PkgConfigAlwaysAddTarget into master

The PKG_CONFIG_ALWAYS_ADD_TARGET, if ON, will force creation of a target for the package even if it would have no properties. This is useful for scenarios where the existence of properties depends on external circumstances. The PKG_CONFIG_ALWAYS_ADD_TARGET is OFF by default and this retains the original behavior.

Note that for example, a simple header-only library could have in its .pc file an entry like this:

Cflags: -I"${includedir}"
Libs:

Depending on the use case it could lead pkg-config to report empty Cflags and Libs for this package. This in turn would cause skipping creation of a corresponding target. Yet, in other circumstances, the same .pc file will report non-empty Cflags.

This creates a difficulty for the build system that can be solved by forcing to create the target always.

Impacting circumstances are environment variables PKG_CONFIG_ALLOW_SYSTEM_CFLAGS and PKG_CONFIG_ALLOW_SYSTEM_LIBS, which if not defined will cause the pkg-config to strip standard paths (like -I"${includedir}" in the example above) from the output. On top of that, there are differences in how --define-prefix works (it modifies the path before the check for skipping) and how PKG_CONFIG_SYSROOT_DIR works (it modifies the path if it wasn’t already skipped).

Open Points

  1. Do we truly need a feature toggle variable? Perhaps the behavior should change unconditionally? I don't see any benefit in not making a target - in the end, it doesn't have to be used.
  2. However, there is a risk some already worked around this issue by making the same-named target themselves. Then again, maybe it would be even better to break such cases.
  3. Or should the variable be a policy instead?
  4. Should tests be added for this? I intended to (within Tests/RunCMake/FindPkgConfig/...), however, I failed to find how to run those tests.

Merge request reports