Age | Commit message (Collapse) | Author |
|
Should help readers being aware of pitfalls
NO_CHANGELOG
|
|
NO_CHANGELOG
|
|
If we are not tracking a specific branch, assume the remote is "origin"
which is git's default.
|
|
I was seeing `error: No such remote 'origin'` in the cmake output.
This commit avoids hardcoding `origin` as the upstream URL and instead
uses the `git rev-parse @{u}` to get the configured upstream.
As a follow-up we may want to check if this should be executed by default,
but for now this fixes a warning that I'm seeing with various projects.
|
|
- Remove deprecated version checks
- Use VERSION_GREATER_EQUAL
|
|
CMake >= 3.0 supports bracket comments, and the reStructuredText
integration code in sphinx/ext/ecm.py already supports extracting
the docs from a bracket comment instead.
Editing documentation without leading line comment markers is more simple,
e,g. when reflowing text over lines.
With ECM meanwhile requiring CMake 3.5 now it is possible to switch
(and thus follow also the approach used by cmake itself).
NO_CHANGELOG
|
|
This way we pass the regex on an actual URL that we may understand.
This is especially useful when url.insteadOf entries are specified in
~/.gitconfig.
|
|
This matters for libraries in the same repository as the application that
also have an AAR that needs to be integrated, as well as QML plugins. For
this to work we need to consider the build directory as a search prefix,
and produce the exact directory layout there that androiddeployqt expects.
For libraries this is then almost transparent for the application build
system, the only thing that needs to be taken care of manually is putting
the corresponding -android-dependencies.xml file into the right place in
the build dir as well. A macro wrapping that might be an option to
centralize that logic here as well in the future.
For QML plugins this is transparent if you have them set up to work without
installation already anyway, otherwise that setup has to be done for this
to work.
Example: https://invent.kde.org/pim/itinerary/-/merge_requests/28
https://invent.kde.org/frameworks/knotifications/-/merge_requests/12 would
presumably also need this (not tested yet).
|
|
regex gets slightly adjusted to only run on kde.org urls, the actual
repo name may now contain slash as well since
a) basenames aren't necessarily unique anymore
b) by extension we need to give fetchpo an actually unique repo path so
it can resolve the underlying project and its translations
|
|
|
|
Summary:
autouic (like automoc) assumes that every ui_*.h include statement it finds
relates to a .ui file that needs generating. this is not always true.
e.g. we have software which generates ui_debug.h which is simply
a qloggingcategory header for the UI category of that software which would
then trip up autouic because it would assume there's a .ui file when there
really isn't one.
unfortunately the ui_ assumption cannot be selectively disabled, so we
can't have explicit listing of .ui in source lists
```
set(foo_SRCS foo.cpp foo.ui)
```
without also getting the not particularly compatible include assumptions.
this should be revisited for kf6 since there isn't a technical need for
files to be called ui_*, they could just as well be *_ui or anything else
so as to not clash with autouic assumption.
autorcc does not suffer from this problem so we can leave it enabled, for
now anyway.
Test Plan: sonnet builds again
Reviewers: apol, nicolasfella, cullmann
Reviewed By: apol
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D23262
|
|
Summary:
I couldn't find any pertinent discussion on the topic but some reviews I
stumbled over did set it on some of our application repos and also wonder
why we don't enable it by default.
autorcc allows more idiomatic use of qrc as they may be used like any
"ordinary" source file and cmake will know what to do with them (namely
compile into relevant cpp for inclusion in target) without the developer
having to worry about anything.
autouic does the same albeit for .ui files.
Test Plan: .qrc files can be added to src list variables and will get automatically generated into cpp files in the binary dir and built into the target
Reviewers: apol
Reviewed By: apol
Subscribers: cgiboudeaux, vkrause, kossebau, apol, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D22805
|
|
Summary: This fixes the Marble build on binary factory.
Reviewers: apol
Reviewed By: apol
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D19223
|
|
Summary:
clazy 1.5 renamed its plugin from from `ClangLazy.so` to
`ClazyPlugin.so` and from `clang-lazy` to `clazy`.
Reviewers: apol, smartins
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D18680
|
|
This is for compatibility with Apple's Xcode
compilers which identify as AppleClang.
Differential Revision: https://phabricator.kde.org/D16816
|
|
|
|
|
|
Summary:
ECMPoQmTools will need to have the translations downloaded at configure time instead of on build time, otherwise it needs an awkward second configure.
To that end we introduce a KDE_L10N_SYNC_TRANSLATIONS variable that allows it to do so.
ECMPoTools will download the translations in the build directory, because cmake shouldn't touch the sources. Have it check the build directory too when the macro is called.
Test Plan: Built analitza translations.
Reviewers: #frameworks, cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: cgiboudeaux, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D14569
|
|
Reviewers: kossebau
Subscribers: #build_system, #frameworks
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D7612
|
|
|
|
VERSION_GREATER_EQUAL was added in CMake 3.7 and ECM still depends on CMake 2.8.12
|
|
Summary:
For compatibility reasons, this is only enabled when projects
upgrade their find_package(ECM) line to request a version >= 5.38.
A little bit like cmake policies: just upgrading ECM is compatible,
while increasing the required version can change behaviour.
Test Plan:
Tested make test in all KF5 frameworks; I have patches
for some of them which I can't commit until this is in.
Reviewers: cgiboudeaux, kfunk
Reviewed By: cgiboudeaux, kfunk
Subscribers: kfunk, #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D7198
|
|
Summary:
- fetchpo now expects the output dirs as named arguments
- new argument for poqm directories where releaseme will put _qt.po files
- variables for both po/ and poqm/ to not repeat the paths all over the
place
Reviewers: apol
Reviewed By: apol
Subscribers: #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5525
|
|
Summary: KDE_L10N_AUTO_TRANSLATIONS is the name of the relevant option
Reviewers: apol
Reviewed By: apol
Subscribers: #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5523
|
|
Summary: It turns out it's more complex than it looks, it's always better to have tests.
Reviewers: sitter, aacid
Reviewed By: sitter
Subscribers: #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5352
|
|
|
|
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: 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
|
|
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
|
|
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
|
|
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
|
|
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: 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/
|
|
|
|
REVIEW: 122359
|
|
This is needed for e.g. kpluginfactorytest in kcoreaddons. Plugins are
searched relative to the directory containing the running executable and
before this commit the unit test was in ${CMAKE_BINARY_DIR}/bin and
the plugin dll in ${CMAKE_BINARY_DIR}/lib, which meant that it could not be
found. This was not a problem on Linux since there the unit test and the
plugin .so ends up in ${CMAKE_CURRENT_BINARY_DIR}.
Reviewed on #kde-windows
|
|
use CMAKE_[RUNTIME|ARCHIVE|LIBRARY]_OUTPUT_DIRECTORY. dlls and executables are built into the bin subdir and import & static libraries and plugins end up in the lib subdir of the build directory.
REVIEW:117965
|
|
This is deliberately modelled very closely on CMake's documentation
system. It's a hefty patch, because it involved changing all the
documentation to be in reStructuredText format. I also cleaned up the
copyright/license statements at the same time.
Note that the find modules contain the full license, due to the fact
that ecm_use_find_module() copies them out of the ECM distribution.
|
|
REVIEW: 115488
|
|
REVIEW: 115477
|
|
We do not want to suppress any warnings about LINK_INTERFACE_LIBRARIES
vs INTERFACE_LINK_LIBRARIES; everything should be using the latter,
since we depend on CMake 2.8.12 everywhere.
REVIEW: 114903
|
|
The old comments were somewhat out-of-date.
|