Fix building akonadiprivate_obj with out of system lzma libs on macOS

src/private/CMakeLists.txt

@@ -62,6 +62,7 @@ if (WIN32)
     set(akonadiprivate_buildsources ${akonadiprivate_SRCS})
 else()
     add_library(akonadiprivate_obj OBJECT ${akonadiprivate_SRCS})
+    target_link_libraries(akonadiprivate_obj ${akonadiprivate_LIBS})
     update_include_directories(akonadiprivate_obj)
     set_target_properties(akonadiprivate_obj PROPERTIES POSITION_INDEPENDENT_CODE 1)
     add_dependencies(akonadiprivate_obj generate_protocol)

[Christophe Giboudeaux]

This breaks the build with older CMake versions:

[ 71s] CMake Error at src/private/CMakeLists.txt:65 (target_link_libraries):

[ 71s] Object library target "akonadiprivate_obj" may not link to anything.

[Filipe Azevedo]

The initial issue i had is that lzma is avaialble, but not in a standard / default path. As this target use / include lzma, it need to have those headers available. So yeah, we don't need explicit linking here as it's a middleware library, but at least update the include path locations so lzma.h can be included. Maybe we would need patch update_include_directories and ensure it add lzma headers instead ?

[Christophe Giboudeaux]

yes, that's a solution.

There's another issue I just see now. FindLibLZMA.cmake provided by the minimum CMake version doesn't provide CMake targets. LibLZMA::LibLZMA was added in CMake 3.14. We need either a local copy or use old style variables.