I note that there are a number of modules that have a construct like: INCLUDE(UsePkgConfig)
IF (NOT WIN32) PKGCONFIG(qca _Qca2IncDir _Qca2LinkDir _Qca2LinkFlags _Qca2Cflags) MESSAGE(STATUS "pkg-config returned ${_Qca2IncDir} for QCA 2 includes") set(QCA2_DEFINITIONS ${_Qca2Cflags}) ENDIF (NOT WIN32) FIND_PATH(QCA2_INCLUDE_DIR QtCrypto PATHS ${_Qca2IncDir} ) MESSAGE(STATUS "QCA2_INCLUDE_DIR has value ${QCA2_INCLUDE_DIR}" ) I don't understand what this is intended to accomplish, but it seems broken to me. Running this module gives me: -- pkg-config returned /usr/local/KDE-4.0/include/QtCrypto for QCA 2 includes -- QCA2_INCLUDE_DIR has value /usr/local/include -- Found QCA2: /usr/local/KDE-4.0/lib/libqca.so The problem is that FiND_PATH is picking up a directory called QtCrypto (in /usr/local/include), rather than the header (also called QtCrypto). This is probably an artifact of my installation, but the fact remains that we are potentially throwing away some of the required -I cflags, because QCA2_INCLUDE_DIR is only ever a single entry (from FIND_PATH), but there could (and are, in this case) several entries). I think we should trust the pkg-config entries, where available: IF (NOT WIN32) PKGCONFIG(qca QCA2_INCLUDE_DIR _Qca2LinkDir _Qca2LinkFlags _Qca2Cflags) MESSAGE(STATUS "pkg-config returned ${_Qca2IncDir} for QCA 2 includes") set(QCA2_DEFINITIONS ${_Qca2Cflags}) ELSE (NOT WIN32) FIND_PATH(QCA2_INCLUDE_DIR QtCrypto PATHS ${_Qca2IncDir} ) ENDIF (NOT WIN32) Note that the same issue potentially applies to the linker / library options. Is there some reason not to trust the pkg-config options, given the chance of breakage that this introduces? Brad
pgpKilDNh2NzI.pgp
Description: PGP signature
_______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem