frankosterfeld / qtkeychain

Platform-independent Qt API for storing passwords securely.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

qtkeychain pollutes ~/.cmake without even installing

frankosterfeld opened this issue · comments

When building qtkeychain on KDAB's CI server, a filef gets copied to ~/.cmake:

~/.cmake/packages/QtKeychain/42f620dcc2197ffaed042f8dc83c1496

That makes other builds (Charm, in particular) find qtkeychain via those files where they shouldn't and try to use the qtkeychain build, which then fails.

The culprit seems to be these lines from CMakeLists.txt:

23396db (Daniel Molkentin 2013-11-13 16:50:38 +0100 184) export(TARGETS ${QTKEYCHAIN_TARGET_NAME} FILE "${PROJECT_BINARY_DIR}/Qt${QTKEYCHAIN_VERSION_INFIX}KeychainLibraryDepends.cmake")
23396db (Daniel Molkentin 2013-11-13 16:50:38 +0100 185) export(PACKAGE Qt${QTKEYCHAIN_VERSION_INFIX}Keychain)

Apparently this causes things to be copied to ~/.cmake on pure cmake/make, without "make install".

@danimo Do you know if these are needed for anything important? the INSTALL directives seem to include similar export-related things, maybe these can be simply removed?

(...and if we fix this, I prepare a release, promised ;) )

Unless I'm not mistaking this commit did not change anything in this regard. This "feature" is there since
80b668a, where the following line was added:

+export(PACKAGE QtKeychain)

According to https://cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#user-package-registry, this causes the hash-based symlink in ~/.cmake to be created.

@dschmidt I guess that was intentional to ensure that a non-installed lib would be preferred? Do we need it?

It's not a bug it's a feature yeah. I found it weird to deal with in the past too. We can delete it. The idea is exactly that you dont need to install