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
