| Age | Commit message (Collapse) | Author | |
|---|---|---|---|
| 2023-05-13 | core: add quotes around paths in CMake files (closes #29) | Sébastien Helleu | |
| 2023-01-01 | core: update copyright dates | Sébastien Helleu | |
| 2022-01-17 | core: update copyright dates | Sébastien Helleu | |
| 2021-01-02 | core: update copyright dates | Sébastien Helleu | |
| 2020-01-04 | core: update copyright dates | Sébastien Helleu | |
| 2019-11-12 | python: use more idiomatic cmake pkg-config linking | Eli Schwartz | |
| 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-10-01 | core: fix style in CMake files | Sébastien Helleu | |
| 2019-08-31 | core: fix compilation of Python plugin on FreeBSD 12.0 (closes #1398) | Sébastien Helleu | |
| 2019-07-31 | build: use pkg-config to properly link python | Eli Schwartz | |
| 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. | |||
| 2019-04-25 | cmake: allow custom libdir (fix #1341) | Ryan Farley | |
| Allows for custom LIBDIR to specified with cmake builds. WEECHAT_LIBDIR is used for a custom Weechat directory, or set from LIBDIR (as LIBDIR used to be set). | |||
| 2019-03-24 | core: add CMake option "ENABLE_CODE_COVERAGE" to compile with code coverage ↵ | Sébastien Helleu | |
| options This option is OFF by default and should be enabled only for tests, to measure test coverage. | |||
| 2019-01-01 | core: update copyright dates | Sébastien Helleu | |
| 2018-11-29 | core: use https for links to GNU GPL license | Sébastien Helleu | |
| 2018-01-05 | core: update copyright dates | Sébastien Helleu | |
| 2017-01-01 | core: update copyright dates | Sébastien Helleu | |
| 2016-01-01 | core: update copyright dates | Sébastien Helleu | |
| 2015-01-01 | core: update copyright dates | Sébastien Helleu | |
| 2014-04-12 | core: use lower case for CMake keywords | Sébastien Helleu | |
| 2014-01-01 | core: update copyright dates | Sebastien Helleu | |
| 2013-01-01 | core: update copyright dates | Sebastien Helleu | |
| 2012-08-02 | core: remove directory "src/plugins/scripts", move script plugins in ↵ | Sebastien Helleu | |
| "src/plugins" | |||
 |
index : weechat | |
| The extensible chat client. | cos |
| summaryrefslogtreecommitdiff |