summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorEli Schwartz <eschwartz@archlinux.org>2019-11-10 10:24:25 -0500
committerSébastien Helleu <flashcode@flashtux.org>2019-11-12 21:19:47 +0100
commit5c8ac69f73821f6b9943ed29b1a2770b203aefd1 (patch)
tree6bc470ba439e31c24d795c12668140e3e70e85e8
parentcmake: vendor in a new version of FindPkgConfig (diff)
downloadweechat-5c8ac69f73821f6b9943ed29b1a2770b203aefd1.tar.xz
weechat-5c8ac69f73821f6b9943ed29b1a2770b203aefd1.zip
python: use more idiomatic cmake pkg-config linking
cmake documentation is absolutely atrocious, and I don't know why they mention all the wrong things to use, and the cargo cult of successfully writing a cmake build definition (copy-pasting what works from other projects) also uses all the wrong things. But it turns out it is possible to correctly link a PkgConfig target despite all that, at least, *iff* you use cmake >= 3.13. I've chosen option 2, which is to vendor in cmake >= 3.13's FindPkgConfig module in the previous commit. Using IMPORTED_TARGET GLOBAL in a pkg-config check will result in a proper linker target being created. For comparison, this is like using meson's dependency() target, except meson forces you to do this by default. The result is that the build system's internal representation of how to link something, is used instead of manually passing build flags defined in variables. This is an important distinction to make, because cmake does not have a list datatype, and instead turns lists into strings separated by ';' which are indistinguishable from, like, strings which contain ';' characters. When you pass the resulting list-which-isn't-really-a-list to link an executable/library, you either need to preprocess the variable to replace ';' with ' ' (just in case there are multiple elements) or use cmake functions which magically know to do this themselves -- or at least, I assume there are cmake functions that correctly handle so-called "lists", or there would be no need for "lists" to exist. The IMPORTED_TARGET will define a bunch of INTERFACE_* properties which do seem to do exactly this. The resulting build definition should actually, correctly, link python, thereby fixing #1398 in a better way.
-rw-r--r--cmake/FindPython.cmake4
-rw-r--r--src/plugins/python/CMakeLists.txt9
2 files changed, 3 insertions, 10 deletions
diff --git a/cmake/FindPython.cmake b/cmake/FindPython.cmake
index dd961c686..e6023dbc9 100644
--- a/cmake/FindPython.cmake
+++ b/cmake/FindPython.cmake
@@ -31,7 +31,7 @@
include(FindPkgConfig)
if(ENABLE_PYTHON2)
- pkg_check_modules(PYTHON python2)
+ pkg_check_modules(PYTHON python2 IMPORTED_TARGET GLOBAL)
else()
- pkg_check_modules(PYTHON python3)
+ pkg_check_modules(PYTHON python3 IMPORTED_TARGET GLOBAL)
endif()
diff --git a/src/plugins/python/CMakeLists.txt b/src/plugins/python/CMakeLists.txt
index 754a89c4e..64a6d6194 100644
--- a/src/plugins/python/CMakeLists.txt
+++ b/src/plugins/python/CMakeLists.txt
@@ -24,14 +24,7 @@ add_library(python MODULE
set_target_properties(python PROPERTIES PREFIX "")
if(PYTHON_FOUND)
- # There's a weird bug on FreeBSD: the value of PYTHON_LDFLAGS is
- # "-L/usr/local/lib;-lpython3.6m" instead of "-L/usr/local/lib -lpython3.6m".
- # This is a temporary hack to fix the value, waiting for a clean fix.
- string(REPLACE ";" " " PYTHON_LDFLAGS "${PYTHON_LDFLAGS}")
-
- include_directories(${PYTHON_INCLUDE_DIRS})
- set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS} ${PYTHON_LDFLAGS}")
- target_link_libraries(python ${PYTHON_LIBRARIES} weechat_plugins_scripts coverage_config)
+ target_link_libraries(python PkgConfig::PYTHON weechat_plugins_scripts coverage_config)
endif()
install(TARGETS python LIBRARY DESTINATION ${WEECHAT_LIBDIR}/plugins)