Age | Commit message (Collapse) | Author |
|
Summary:
CMP0053 specifies that:
- Expansion of ``@VAR@`` reference syntax defined by the
``configure_file()`` and ``string(CONFIGURE)``
commands is no longer performed in other contexts.
replace it with the $ variable syntax.
Test Plan: manual
Reviewers: #frameworks, dfaure
Reviewed By: dfaure
Subscribers: #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5017
|
|
|
|
Summary: Otherwise the cmake cache has noisy values.
Test Plan: Recreated a project, it's not listed first thing when calling ccmake.
Reviewers: #frameworks, dfaure
Reviewed By: dfaure
Subscribers: #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D4630
|
|
Summary:
On Linux, inotify always exists; all you need is the header file.
On the BSDs, inotify is provided through a shim to kqueue, which
must be installed separately. Add a FindInotify to help sort
that out.
Based on RB 129316 and RB 129549.
Test Plan:
- On FreeBSD, reliably detects presence of libinotify in $LOCALBASE,
- Needs testing on Linux that it does find the header file.
Reviewers: apol, arrowdodger, #build_system, #frameworks, tcberner, ervin, skelly, dfaure, kfunk
Reviewed By: tcberner, kfunk
Subscribers: kfunk, #freebsd
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D3826
|
|
|
|
With some combination of PyQt/compiler this breaks the build of
kcoreaddons.
This reverts commit 2e20aeab6e86670a66ff99a7b79120c4004b4d22.
|
|
This should have been removed in a prior commit.
|
|
|
|
|
|
Don't export API which has visibility "hidden".
Visibility attributes on variables are ignored, but call the generic
method anyway.
Remove checks for macros which obscure the attributes. Processing the
attribute directly means that is not needed.
|
|
De-duplicate it between variables and functions. The callers already
handle reporting the removal.
|
|
|
|
Fix the anchoring of the regular expression matching to cover the
complete input. This was an oversight and should have no visible
effects except that if new fields are added to a rule database,
existing rules with wildcards will greedily match the new fields.
|
|
Summary:
Reviewers: smartins, alexmerry, apol
Reviewed By: apol
Subscribers: #windows, #build_system, #frameworks
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D4389
|
|
|
|
|
|
|
|
|
|
|
|
|
|
REVIEW: 129724
|
|
|
|
|
|
Clang API is odd.
|
|
|
|
|
|
|
|
Don't prepend a namespace to it as we do otherwise with enum/flags.
|
|
Summary:
Disables alternative tokens for &&, ||, etc.. They're are not supported
by MSVC out of the box, thus using them will limit the portability of
the code. There *are* options to make alternative tokens available under
MSVC [1], but I think we shouldn't promote the usage of them.
From the GCC documentation:
-fno-operator-names: Do not treat the operator name keywords and,
bitand, bitor, compl, not, or and xor as synonyms as keywords.
[1] http://stackoverflow.com/questions/555505/when-were-the-and-and-or-alternative-tokens-introduced-in-c
Reviewers: #frameworks, #buildsystem, ivan
Reviewed By: ivan
Subscribers: rakuco, elvisangelaccio
Differential Revision: https://phabricator.kde.org/D3850
|
|
|
|
Only one directory may provide the PyKF5 namespace, so if testing
KAuth, which depends on KCoreAddons, both have to be in the same
directory. That means that the KAuth tests can only be run
post-intallation which doesn't really cause problems.
|
|
Allow modifying the name also.
|
|
Don't process the same function name twice.
|
|
|
|
The KConfig build creates two libraries and they should both be output
in the same place so that they can be tested together.
|
|
It is not appropriate to decorate each forward declaration with the SIP
attribute /External/. That is only needed for forward declarations of
types which are defined in a different module.
Local forward declarations can be omitted from the sip code. In sip
code, a forward declaration followed later by a full class definition is
an error.
Omit forward declarations unless they are decorated with the external
attribute. Introduce a rules database for consumers to decorate them
with the attribute as required.
|
|
Custom rules should be able to deal with lists in these cases. This is
already the case for function parameters.
|
|
|
|
|
|
|
|
Packagers can execute this script with
cmake -D PYTHON_UMBRELLA_MODULE_FILE=/where/ever/PyKF5/__init__.py -P /path/to/ECM/find-modules/GeneratePythonBindingUmbrellaModule.cmake
Soon, this is likely to do more than create an empty file.
|
|
Use find_package to locate the executable.
|
|
The LLVM project has picked a new version scheme
http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html
which means that major version numbers will be bumped more regularly,
the minor version will remain at zero, and the patch version will be
bumped. We will have to see how distros respond in terms of file
naming.
|
|
The suffix is used later to run the clang executable in order to
determine the built-in system includes.
|
|
The dist-packages directory which is currently hardcoded is unsuitable
to non-debian package creation. Set the directory to 'site-packages' by
default.
|
|
Currently this is rather simple, allowing only matching typedefs by
name. If we need more later, we can extend the interface. This will
make it possible to add bindings for the K18n framework.
|
|
|
|
Don't use the text 'Parse error' for warnings, which might confuse IDEs.
|
|
The Python logging module uses logging severities with numerical values
which form a sequence in steps of 10. The Clang cindex.Diagnostic
numerical values use a step size of 1, so the two are incompatible.
Introduce a mapping function so that appropriate errors get issued when
attempting to build the bindings. The logging module has one surplus
diagnostic level, but we simply never use it.
BUG: 374801
|
|
The generator expression here looks like it should work, but it does not
set the appropriate flags for compilation. It seems that the
CXX_STANDARD property is not yet populated at the time the generator
expression is evaluated (to be investigated later).
This came to light because users of Qt 5.7+ attempted to generate the
bindings, but they encountered errors. The step of using libclang to
parse the provided headers was actually failing, but that was not
noticed, perhaps because the logging infrastructure in sip_generator
does not emit it (to investigate later).
BUG: 374801
|