The cmake find file was missing, but CoreFoundation being a system
framework, no need to search for it.
Update code to not use deprecated functions/data structure
CSSM_DATA and SecCertificateGetData have been deprecated since 10.7.
This patch uses SecCertificateCopyData which is the official
replacement.
Reviewed at https://git.reviewboard.kde.org/r/125800/
Currently qca links to the Carbon framework for building however the mac
specific code don't use any Carbon classes but CoreFoundation. This patch
aims to update the code and build script to link to the more generic
CoreFoundation framework which may also allow to build it on iOS (not
verified).
REVIEW: 121703
The previous code (present since the file was created) mixed different
checks that required different expansions:
* `if (ENV{foo})' will always evaluate to false even if $ENV{foo} is
set, and may even be a CMake bug.
* `if (EXISTS ...)' expects an actual string, not an variable that has
not been expanded.
It is not clear why the code expects QC_CERTSTORE_PATH to be an
environment variable instead of a regular variable passed to CMake in
the first place, but that can be changed in another commit.
REVIEW: 122062
It's not properly. Martin Klapetek is not QCA developer. So it's not
correct that he said "Ship it!".
Properly way
cmake -DQCA_SUFFIX=qt5 ...
and in CMakeLists.txt of your project.
find_package(Qca NAMES Qca-qt5)
This reverts commit c32bc6f1bc9befe5f89d3572eb28e0d591a2e3b2.
- if QT4_BUILD is not defined *and* Qt5Core is found build with soname
qca-qt5
- rename cmake package to reflect the suffix i.e. with a Qt5 build it is
find_package(Qca-qt5) rather than find_package(Qca)
- the imported cmake target also reflects suffix so "Qca-qt5" is the
cmake link target for qt5 and "Qca" for qt4 builds
this retains 100% compatibility with regular qca while also offering 100%
coinstallability of the qt5 build.
REVIEW: 121633
Many linux distribution provides both version of Qt: Qt4 and Qt5.
These versions are binary is incompatible and any qt-based library
compiled against such Qt versions will be binary incompatible with
one another. In common case library name must not be related with
based libraries. In our case Linux users want to have both versions
QCA installed in their system. I will do not implicity rename Qt5
based QCA but just warn user and allow him explicity set QCA_SUFFIX.
Distros often do not allow use rpath in packages (Fedora and Debian for example).
If need to have rpath CMAKE_INSTALL_RPATH can be set in command line.
1. SafeTimer now is common and public class. All plugins use this
implementation.
2. Added debug messages in SafeTimer. Uncomment SAFETIMER_DEBUG to
enable.
3. TimerFixer skips SafeTimer objects. No need extra fixes for
SafeTimer. But can be problems with children of SafeTimer I
believe no such.
Retrieve plugin paths. It consists of:
1. QCA_PLUGIN_PATH environment if set.
2. QCoreApplication::libraryPaths() .
3. Directory where plugins were installed.
QCA_PLUGIN_PATH is paths list like PATH or QT_PLUGIN_PATH.
It uses system path separator. ";" on Windows and ":" on Unix.
Also qcatool now uses this function.
After the latest commit cmake is trying to use relative paths.
But in pc file can be used only absolutes. So it is need to
generate this file before relative paths will be calculated.
This reverts commit 38e0665127650b3db5676c1dd5f0ffeb8cdb176f.
This change is incorrect, as Qt/QCA does not look within $pluginDir/qca/crypto when loading it's plugins.
Instead, it expects to find them within the $pluginDir/crypto/ subdirectory which no longer exists with this change.
While the use of lib/qca/ is non-standard for plugins, existing code within the CI scripts is able to handle this abnormality.
Normal Qt libraries which use plugins also function normally on the CI system.
The change as it stands does not work with Qt 4 and breaks all tests which are reliant upon QCA on the CI system.
As it appears a decision needs to be made on where QCA plugins should live and how they should be loaded i'm reverting this change to allow the tests to pass again.
CCMAIL: aleixpol@kde.org
CCMAIL: drizt@land.ru
CCMAIL: stephane@mankowski.fr
CCMAIL: kde-core-devel@kde.org
CCMAIL: kde-frameworks-devel@kde.org
