The Qt pkg-config files ship as e.g:
prefix=/Users/torarne/build/qt/6.x-prefix-no-fw/install
exec_prefix=${prefix}
bindir=${prefix}/bin
libexecdir=${prefix}/libexec
libdir=${prefix}/lib
includedir=${prefix}/include
Name: Qt6 Widgets
Description: Qt Widgets module
Version: 6.13.0
Libs: -L${libdir} -lQt6Widgets
Cflags: -I${includedir}/QtWidgets -I${includedir} -DQT_WIDGETS_LIB
Requires: Qt6Core Qt6Gui
The -DQT_WIDGETS_LIB define is used to allow e.g. QtGui's headers to expose APIs that are only valid if the consuming app is depending on both QtGui and QtWidgets.
SPM complains about this though:
warning: 'qt-swift': prohibited flag(s): -DQT_WIDGETS_LIB
And strips the unsupported flag from the final compilation flags passed to consumers of the systemLibrary.
Unfortunately this warning shows up for every systemLibrary in the package, even if the consumer doesn't depend on a product that depends on any systemLibrary, so in a package with 100+ targets it gets quite spammy. It also outputs on every build, even incremental noops.
The resulting module builds of the QtWidgets and QtGui libraries does work in the end, but lacking the defines they will of course miss a few APIs here and there.
Is there a way to fix this? Should SPM allow -D flags through perhaps?
I considered changing Qt to use __has_include for the detection instead, looking up a header that could only be found if the relevant library's include paths were part of the consuming build, but then I noticed the module cache doesn't treat __has_include variance as a cache-busting signal (as opposed to defines, AFAICT, via e.g. config_macros). Is that intentional?
I also noticed that unsupported flags end up breaking the build flags passed through to build plugins via the context, as the error handling for unsupported flags in PluginContextSerializer.swift bails out completely, as opposed to BuildPlan.swift that just warns. Is this a bug in the plugin context serializer? If so I can file one with reproducer.
Thanks for any insights!