2007-05-21 16:30:04 +00:00
|
|
|
#
|
2019-01-01 15:40:51 +01:00
|
|
|
# Copyright (C) 2003-2019 Sébastien Helleu <flashcode@flashtux.org>
|
2010-06-22 19:46:28 +02:00
|
|
|
# Copyright (C) 2009 Julien Louis <ptitlouis@sysif.net>
|
|
|
|
|
#
|
|
|
|
|
# This file is part of WeeChat, the extensible chat client.
|
|
|
|
|
#
|
|
|
|
|
# WeeChat is free software; you can redistribute it and/or modify
|
2007-05-21 16:30:04 +00:00
|
|
|
# it under the terms of the GNU General Public License as published by
|
2007-07-02 12:25:13 +00:00
|
|
|
# the Free Software Foundation; either version 3 of the License, or
|
2007-05-21 16:30:04 +00:00
|
|
|
# (at your option) any later version.
|
|
|
|
|
#
|
2010-06-22 19:46:28 +02:00
|
|
|
# WeeChat is distributed in the hope that it will be useful,
|
2007-05-21 16:30:04 +00:00
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
|
#
|
|
|
|
|
# You should have received a copy of the GNU General Public License
|
2018-11-29 23:16:07 +01:00
|
|
|
# along with WeeChat. If not, see <https://www.gnu.org/licenses/>.
|
2007-05-21 16:30:04 +00:00
|
|
|
#
|
|
|
|
|
|
|
|
|
|
# - Find Python
|
|
|
|
|
# This module finds if Python is installed and determines where the include files
|
|
|
|
|
# and libraries are. It also determines what the name of the library is. This
|
|
|
|
|
# code sets the following variables:
|
|
|
|
|
#
|
|
|
|
|
# PYTHON_EXECUTABLE = full path to the python binary
|
2019-07-24 14:50:36 -04:00
|
|
|
# PYTHON_INCLUDE_DIRS = path to where python.h can be found
|
|
|
|
|
# PYTHON_LIBRARIES = path to where libpython.so* can be found
|
|
|
|
|
# PYTHON_LDFLAGS = python compiler options for linking
|
2007-05-21 16:30:04 +00:00
|
|
|
|
2019-07-24 14:50:36 -04:00
|
|
|
include(FindPkgConfig)
|
2007-05-21 16:30:04 +00:00
|
|
|
|
2019-07-01 21:26:48 +02:00
|
|
|
if(ENABLE_PYTHON2)
|
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.
2019-11-10 10:24:25 -05:00
|
|
|
pkg_check_modules(PYTHON python2 IMPORTED_TARGET GLOBAL)
|
2014-04-12 18:00:27 +02:00
|
|
|
else()
|
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.
2019-11-10 10:24:25 -05:00
|
|
|
pkg_check_modules(PYTHON python3 IMPORTED_TARGET GLOBAL)
|
2014-04-12 18:00:27 +02:00
|
|
|
endif()
|
