qpid-cpp
qpid-cpp copied to clipboard
QPID-7148: Use more modern CMake install machinery for better QpidConfig.cmake
Turns out, CMake is happy to generate a lot of the QpidConfig.cmake file for us, see
- https://gitlab.kitware.com/cmake/cmake/-/issues/19560
- https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-packages
- https://cmake.org/cmake/help/latest/guide/importing-exporting/index.html#exporting-targets
- https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html#example-generating-package-files
- https://cmake.org/cmake/help/latest/guide/tutorial/Packaging%20Debug%20and%20Release.html
This is analogous change to PROTON-2254 for Qpid Proton.
TODO
- [x] Check this solves my problems in downstream project, https://github.com/rh-messaging/cli-cpp
- [ ] Check that Windows build (with the d versions for debug DLLs) is still working
It appears that this really fixes the build for me https://github.com/rh-messaging/cli-cpp/pull/71
The issue is that Bazel moves the installed library around, and requires QpidConfig.cmake
to contain relative paths. Otherwise, attempt is made to fetch libraries from original install location, which is prevented by Bazel sandbox and therefore build fails.
As far as I can remember, federation tests are broken and failure can be ignored
6: federation.FederationTests.test_dynamic_direct_shared_queue ............. fail
6: Error during test: Traceback (most recent call last):
6: File "/home/travis/.local/bin/qpid-python-test", line 340, in run
6: phase()
6: File "/home/travis/build/apache/qpid-cpp/Build/src/tests/federation.py", line 2592, in test_dynamic_direct_shared_queue
6: self.assertNotEqual(_c.msgsToClient, 0, "Messages did not pass over link as expected.")
6: File "/usr/lib/python2.7/unittest/case.py", line 522, in assertNotEqual
6: raise self.failureException(msg)
6: AssertionError: Messages did not pass over link as expected.
https://app.travis-ci.com/github/apache/qpid-cpp/builds/256978344#L2108