| Age | Commit message (Collapse) | Author |
|---|
|
In python 3.8, in order to link to -lpython3.8, you need to use the
exported pkg-config interface 'python3-embed' (or 'python3-config --libs
--embed'), see https://bugs.python.org/issue36721 for details.
|
|
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.
|
|
The current one is anciently ancient, and dates back to commit
4d2925ef1c3dd5df288be55557358b60cbb0926e which vendored this "for old
versions of cmake". Well, currently it just stops using new versions of
FindPkgConfig, so we're stuck on the 2006 version from cmake 2.5.0.
Instead of deleting it entirely (the minimum version of cmake is
currently 3.0) make this vendored file continue to be useful by using it
to vendor in the latest version of FindPkgConfig from cmake 3.16.0-rc3
with a bunch of useful improvements.
|
|
|
|
(issue #1404)
|
|
|
|
This is file is provided by CMake and is not needed any more. Moreover, it
causes an error on FreeBSD (TCL not found), even if TCL was properly detected
and used during the build.
|
|
fixes incorrect (non)detection of libpython3.Ym.so due to PEP 3149 since
python's officially exported build flags know how to correctly link to
python.
|
|
The CMake option ENABLE_PYTHON3 is renamed to ENABLE_PYTHON2, to use Python 2
first then fallback on Python 3.
In the same way, the configure option --enable-python3 is renamed to
--enable-python2, to use Python 2 first then fallback on Python 3.
|
|
|
|
search
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This was causing a dependency missing in debian packaging.
|
|
php: use find_library to find libphp7.so
|
|
|
|
|
|
|
|
This plugin requires PHP >= 7.0.
|
|
|
|
|
|
|
|
with Windows subsystem for Linux (closes #770)"
This reverts commit 399636f98453bdc1fca19b4dbc742993549aa6c3.
|
|
Windows subsystem for Linux (closes #770)
|
|
|
|
|
|
|
|
|
|
core: do not hardcode iconv library name
|
|
|
|
|
|
When linking against a python with shared libraries, this script ONLY asked for the LD flags, not any additional libraries. This could result in a condition where required libraries (such as libutil on Centos 6.7 against Python 2.7) are not loaded and the load of the plugin thus fails. This change asks the python being linked against which libraries it was linked using, and then ensures those are also linked against by the python plugin for weechat.
|
|
|
|
The package "pkgconf" is not installed by default on FreeBSD 10.2, so
the detection of Ruby was failing.
|
|
Instead of splitting ${ICONV_LIBRARY}'s path and then assuming the
library is called "libiconv.so", use ${ICONV_LIBRARY}'s entire value in
the calls to check_library_exists().
If that is not done, the iconv detection fails if one sets ICONV_LIBRARY
to, for example, /usr/lib/libc.so, as the previous calls would still
pass "-liconv" to the linker instead of the chosen value.
|
|
|
|
|
|
|
|
With this fix, WeeChat can be built without tests (if cpputest is not found),
without having to explicitely disable tests ("-DENABLE_TESTS=OFF").
|
|
|
|
This plugin was originally written by Koka El Kiwi
(repository: https://github.com/KokaKiwi/weechat-js-plugin).
This plugin uses Google V8 engine to execute JS scripts.
|
|
|
|
|
