Age | Commit message (Collapse) | Author |
|
Summary:
Broken since we started to treat Clang and AppleClang differently (with
the switch to CMake 3.0)
FIXED-IN: v5.34.0
BUG: 377933
Reviewers: apol, rjvbb
Reviewed By: apol, rjvbb
Subscribers: #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5379
|
|
|
|
Summary:
Otherwise it would pollute the namespace and weird things happened on
some projects
Reviewers: bshah
Reviewed By: bshah
Subscribers: #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5332
|
|
|
|
Summary:
Makes it possible to fetch translations when building the project. To do so
it fetches kde:releaseme and uses the new fetchpo.rb program to download the
translations into the build directory.
This should make it much easier to integrate translations in the development
process.
Test Plan: Downloaded and installed translations for some projects
Reviewers: #frameworks, #build_system, kfunk, ltoscano, aacid, ilic, sitter
Reviewed By: sitter
Subscribers: sitter
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5143
|
|
Summary:
Add it to KDECompilerSettings.cmake instead of
KDEFrameworkCompilerSettings.cmake.
Users can then just enable -pedantic without worrying about the
gnu-zero-variadic-macro-arguments warning.
This fixes some warnings in e.g. kdenlive
Reviewers: kossebau, apol, dfaure
Reviewed By: apol
Subscribers: apol, #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5302
|
|
https://phabricator.kde.org/D5089
|
|
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:
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
|
|
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
|
|
This reverts commit d1d637fadd6dad68995d44101250ebbc3307ed0b.
This is far too noisy.
The correct steps for this kind of change are:
* Enable the warning locally
* Take the action recommended by the warning in the code, and push the
result
* Push the warning on everyone to enforce that the code stays fixed for
the future
|
|
Summary:
If you just built the software without installing it and then run ctest,
this will systematically fail while trying to read install_manifest.txt.
With this patch this case is now handled gracefully, not forcing to
install to have a test suite which fully passes.
Reviewers: #frameworks, apol
Differential Revision: https://phabricator.kde.org/D3860
|
|
REVIEW: 129724
|
|
Summary:
Colored compiler warnings in ninja output only work with the
`-fdiagnostics-color=always` flag.
See https://github.com/ninja-build/ninja/issues/814 for a rationale.
This commit adds such flag in ecm for gcc >= 4.9 and clang >= 3.5,
and only if the CMAKE_GENERATOR is Ninja.
Test Plan: ninja+gcc and ninja+clang now show nice colored compiler warnings.
Reviewers: #frameworks
Differential Revision: https://phabricator.kde.org/D3733
|
|
While unusual it is not impossible to use GCC on Macs, esp. not when
using older OS X versions. Intel also makes compilers for Mac, so it may
in fact be better to rewrite the check ((GNU or Clang or Intel) IF NOT
(APPLE or WIN32)).
|
|
Apple's clang v3.1 corresponds to clang 3.1 and started following the
Xcode versioning scheme from 4.4 onwards (though loosely). An overview
of the version correspondance can be found here:
https://gist.github.com/yamaya/2924292
|
|
Summary: When running tests with hardcoded `cmake`, it get's suffixed to the project's build path. Setting it with an absolute path ensures using the right cmake binary.
Test Plan: Compiled, installed. Used to generate tests for kdev-embedded. `cmake` binary is now prefixed with the absolute system path, and no longer with the project's build dir.
Reviewers: kfunk, #frameworks, apol
Reviewed By: kfunk, apol
Subscribers: kfunk
Differential Revision: https://phabricator.kde.org/D3568
|
|
also correct link to clazy's README.md (former README)
|
|
REVIEW: 128806
|
|
that simulates MSVC."
This reverts commit 4b8e8dcc8856d8f438860783e7641d02d1c05630.
|
|
simulates MSVC.
REVIEW: 128779
|
|
Guard variable we used to ensure this doesn't happen was not scopped to
parent and hence was being reset when funciton returns
REVIEW: 128917
|
|
REVIEW: 128780
|
|
GIT_SILENT
|
|
At the moment, we're validating it in build.kde.org, but I feel it will be
easier for developers to test if we do so locally.
This patch does it by seeing which *.appdata.xml files are being installed
and validating them. This way we can keep it generic for all KDE projects.
REVIEW: 128533
|
|
|
|
Update preferred path of appstream data files to /usr/share/metainfo
Requires modern versions of appstream metadata generators.
FEATURE
REVIEW: 128174
|
|
Summary:
Instead of using "share" use "${BIN_INSTALL_DIR}/data" on Windows,
this is the location provided by QStandardPaths for GenericDataLocation
on Windows.
Reviewers: dfaure
Reviewed By: dfaure
Subscribers: kfunk
Differential Revision: https://phabricator.kde.org/D1873
|
|
Better wait a little until applying this change, since this might break
assumptions, and we don't know yet if all distros are using a recent enough
AppStream (Generator) release.
This reverts commit 4b7a90bfe7a3e2eb3ae83c946c182a79fabc51e3.
|
|
As per AppStream release 0.9.4
|
|
Make Qt and ECM-based projects use the same directory sctructure (i.e.
where plugins are, libs, etc.) by default. Otherwise it creates a tiny mess
that might be controlled but usually won't.
In the end, otherwise, people need to keep adapting their systems with
environment variables anyway. All distros end up setting always this
setting as ON, as well as brave developers who don't have separate prefixes
for Qt and KDE.
REVIEW: 127169
|
|
templates are very useful as teaching tool in order to make
a minimal application that uses a certain framework.
templates in the KAppTemplate repository will always get forgotten
(plus kapptemplate is not really necessary as they work in kdevelop as well)
An ideal situation would be frameworks having templates in their own repos
with templates of barebone apps using the main framework features.
In order to do that, the cmake stuff needed in order to correctly install
a template needs to be ported to a place avaiable to all frameworks
REVIEW:126185
|
|
We recommend including KDE "settings" modules with NO_POLICY_SCOPE, both
so we can resolve this issue and to allow us to deal with similar things
in the future.
REVIEW: 126535
|
|
REVIEW: 126414
|
|
Example:
CMake Warning (dev) at
Z:/kderoot/share/ECM/kde-modules/KDEFrameworkCompilerSettings.cmake:50(elseif):
Policy CMP0054 is not set: Only interpret if() arguments as variables or
keywords when unquoted. Run "cmake --help-policy CMP0054" for policy
details. Use the cmake_policy command to set the policy and suppress this
warning.
REVIEW: 126405
|
|
This reverts commit 1e8e0da3eb475bb8b78baa54cb0c34b913c2dc5d.
I don't want this going into a release without further review, as well
as documentation and tests, so I'm reverting it (at least temporarily).
See emails on kde-commits mailing list for further rationale.
CCMAIL: notmart@gmail.com
|
|
templates are very useful as teaching tool in order to make
a minimal application that uses a certain framework.
templates in the KAppTemplate repository will always get forgotten
(plus kapptemplate is not really necessary as they work in kdevelop as well)
An ideal situation would be frameworks having templates in their own repos
with templates of barebone apps using the main framework features.
In order to do that, the cmake stuff needed in order to correctly install
a template needs to be ported to a place avaiable to all frameworks
REVIEW:126185
|
|
REVIEW: 126090
|
|
from the normal qt.io installer on mac os
we can revisit this change, if it leads to problems for mac ports or homebrew
REVIEW: 125614
|
|
Reviewed at https://git.reviewboard.kde.org/r/125163/
|
|
This warning is emitted for every qCDebug() call and is not useful.
REVIEW: 125031
|
|
REVIEW: 124763
|
|
(they are slower). And enable them on MSVC now that we rely on Qt 5.3, as the comment said.
REVIEW: 124762
|
|
This prevents accidental "leaking" of symbols from internal code, such
as flex/bison generated parsers.
REVIEW: 124740
|
|
|
|
REVIEW: 122359
|
|
BUG: 341683
FIXED-IN: 1.7.0
REVIEW: 121999
CHANGELOG: KDEInstallDirs: warn about mixing relative and absolute
installation paths on the command line
|
|
|
|
Cache variables such as CMAKE_INSTALL_BINDIR may be used by other
modules included from parallel parts of the tree, so we should not touch
them. We still override them in the runtime environment, but this will
not interfere with parallel subtrees of the project.
As part of this, the order of precedence of variables specified on the
command line is changed, so that KDE_INSTALL_* is considered first
(although it is still considered "undefined" in the documentation). This
means that if you only specify CMAKE_INSTALL_BINDIR, that will be used
by both KDEInstallDirs and GNUInstallDirs, but if you specify both that
and KDE_INSTALL_BINDIR, KDEInstallDirs will use KDE_INSTALL_BINDIR
instead. This is probably not too useful, but seems more useful than
any other arrangement.
BUG: 342717
REVIEW: 121982
|