Age | Commit message (Collapse) | Author |
|
|
|
|
|
With min required cmake version now bumped to 3.5, the policy for CMP0048
needs to be set explicitly to old now to prepare what the tests check.
Fixup for 5ca01895e3c50322f79feeef5054d7f28b164d68
|
|
Summary: Like we have for other FD.O projects like DBus service files
Test Plan:
Unit test passes
Used in another project, and it installed to the correct place
Reviewers: apol
Reviewed By: apol
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D25107
|
|
Reviewers: #frameworks, #build_system, apol, dfaure
Reviewed By: apol, dfaure
Subscribers: dfaure, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D24990
|
|
GIT_SILENT
|
|
Summary: Fixes regression from https://phabricator.kde.org/D24841
Reviewers: cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D24882
|
|
Summary:
This allows later modification of the selected standard.
Raise C from C89 to C90 as C89 is not supported by the CMAKE flag
https://cmake.org/cmake/help/v3.16/prop_tgt/C_STANDARD.html#prop_tgt:C_STANDARD
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D24841
|
|
|
|
GIT_SILENT
|
|
|
|
GIT_SILENT
|
|
Summary:
Provides a clang-format target if wanted
Example usage:
include(KDEClangFormat)
# add clang-format target for all our real source files
file(GLOB_RECURSE ALL_CLANG_FORMAT_SOURCE_FILES autotests/src/*.cpp autotests/src/*.h src/*.cpp src/*.h templates/*.cpp templates/*.h)
kde_clang_format(${ALL_CLANG_FORMAT_SOURCE_FILES})
Test Plan: Tried that above usage thingy in KTextEditor
Reviewers: #frameworks, dfaure
Reviewed By: dfaure
Subscribers: zzag, sitter, mwolff, ochurlaud, nalvarez, kossebau, aacid, davidedmundson, dhaumann, apol, ognarb, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D24568
|
|
GIT_SILENT
|
|
|
|
More friendly to users which mix arguments DEPRECATED_BASE_VERSION &
EXCLUDE_DEPRECATED_BEFORE_AND_AT, but e.g. allow the latter to be
configured during library build setup
GIT_SILENT
|
|
GIT_SILENT
|
|
GIT_SILENT
|
|
GIT_SILENT
|
|
Summary:
Generates additional macros in the export header which can be used for
fine-grained disabling of warnings & visibility as well as excluding from
the build.
Reviewers: #frameworks, #build_system
Subscribers: chehrlic, dfaure, cgiboudeaux, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D23789
|
|
Summary:
simply sets a variable when the source is under version control. use it to
auto-enable Debug builds. there are also plans to switch special assertion
logic on in KIO when used from git, so there definitely is a more generic
use case of wanting to control behavior based on whether it the source is
likely used to make a development or production build.
conceivably the module could be used in the future to get git rev-parse or
the like, hence the generic name.
Test Plan: with .git the var is true, without it is false
Reviewers: kde-buildsystem, dfaure
Reviewed By: dfaure
Subscribers: apol, kossebau, kde-frameworks-devel
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D24159
|
|
When using the Emscripten toolchain, there is no library linkage
necessary (there is no library) and the system include search paths
provide EGL headers.
Reviewed By: vkrause
Differential Revision: https://phabricator.kde.org/D24182
|
|
As intended by original code, to generate consistent output per
this document for the given lists of variables
GIT_SILENT
|
|
Summary:
Allows to have headers be found by doxygen, e.g. to properly process
preprocessor macros.
Reviewers: #build_system, dfaure
Reviewed By: dfaure
Subscribers: dfaure, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D23791
|
|
|
|
Summary:
The initial API asked to have custom C++ code to be parsed as string
arguments. As any ";" in such strings would be treated as list separators,
the initial API as workaround required to encode those in the passed
code text with "@SEMICOLON@".
As alternative variant the approach from the GENERATE_EXPORT_HEADER()
macro and its CUSTOM_CONTENT_FROM_VARIABLE is now used, where instead
the name of the variable is passed, from which then the full code could
be fetched and directly used.
As API user one no longer can pass code snippets directly inline as
argument, but no longer needs to use the awkward @SEMICOLON@.
As ECMAddQtDesignerPlugin is not yet part of a released version,
the API can be still changed.
Reviewers: #frameworks, #build_system, vkrause
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D23725
|
|
Port of upstream commit https://gitlab.kitware.com/cmake/cmake/commit/18365587c86396f988e256b5acf4d2312f3be2bb
Differential Revision: https://phabricator.kde.org/D23497
|
|
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 follows where Qt installs those, and thus androiddeployqt looks for
them. Currently this is hardcoded in knotifications for example, seems
cleaner to have this here.
Reviewers: #build_system, #android, apol
Reviewed By: #android, apol
Subscribers: apol, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D23131
|
|
|
|
Summary:
ECMAddQtDesignerPlugin provides two macros that can be used to
replace the usage of the tool kgendesignerplugin from KDesignerPlugin.
This allows to have ECM-using libraries to create Qt Designer plugins without
the need for another separate tool.
For that purpose option structure & defaults are inspired from that one, to
allow simple porting. Main difference is that ECMAddQtDesignerPlugin
expects the widget metadata definition to be done in CMake code,
using a dedicated function, instead of in a ini-style separate ".widgets" file.
Porting of ".widgets" files basically means:
copy content into cmake, transform ini code into arguments to util method.
Key names need a bit of adaption, current names are open for dicussion.
Porting example:
```
[KActionSelector]
IncludeFile=kactionselector.h
ToolTip=A widget for selecting and arranging actions/objects
Group=Views (KF5)
```
gets
```
ecm_qtdesignerplugin_widget(KActionSelector
INCLUDE_FILE kactionselector.h
TOOLTIP "A widget for selecting and arranging actions/objects"
GROUP "Views (KF5)"
)
```
Reviewers: #build_system, #frameworks
Subscribers: apol, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D22724
|
|
|
|
Summary:
It's especially when KDE_INSTALL_USE_QT_SYS_PATHS=OFF that the different environment variables will have to be initialised.
This adds a message that should tell users about the script so they have a hint of what is going on.
Reviewers: #frameworks, albertvaka, cgiboudeaux
Reviewed By: albertvaka, cgiboudeaux
Subscribers: cgiboudeaux, albertvaka, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D22580
|
|
Summary: If no prefix is passed, use ECM's by default, instead of defaulting to /usr/local which isn't optimal in any case.
Reviewers: cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: cgiboudeaux, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D22676
|
|
Summary:
The idea comes from
https://blog.kitware.com/cmake-and-the-default-build-type/
but I adapted it to leave it empty for tarballs, to avoid messing up
distribution packaging.
The goal is to make this more sensible for [new] developers who just
run cmake and end up with a "no debug symbols, no optimizations" build,
i.e. the one and only completely useless combination of those two flags.
Possible risk: distributions who compile from git checkouts...
Test Plan: "mkdir build ; cd build ; cmake .." in kblog leads to CMAKE_BUILD_TYPE=Debug
Reviewers: kde-buildsystem, cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: cgiboudeaux, apol, kde-frameworks-devel
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D22667
|
|
|
|
Summary: It's supposed to be uppercase, cmake was warning about it.
Test Plan: Now it builds as well, but cmake doesn't complain.
Reviewers: #frameworks, #android, vkrause
Reviewed By: #android, vkrause
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D22317
|
|
|
|
|
|
Summary: kdebugsettings categories files
Reviewers: dfaure, cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: kossebau, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D21313
|
|
Summary:
Strict iterators can't be used on Windows, they lead to a link error
when application code iterates over a QVector<QPoint> for instance, unless
Qt itself was also built with strict iterators.
See example at https://bugreports.qt.io/browse/AUTOSUITE-946
Technically this would be fine for mingw, but not for MSVC neither
clang-cl (which also uses the MSVC ABI). I think it's fine to just
disable it for all Windows compilers, since any iterators misuse
will be detected on Unix anyway.
Test Plan: None, I'm relying on Volker's findings.
Reviewers: vkrause, dvratil
Reviewed By: dvratil
Subscribers: apol, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D21314
|
|
|
|
Summary:
Find C++ shared lib path using regex. This change makes finding path
independent of the order in which it was added by cmake.
Reviewers: apol
Reviewed By: apol
Subscribers: kde-buildsystem, kde-frameworks-devel
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D20558
|
|
Summary:
Don't include same dependency twice, one which was found
from `readelf` in `specifydependencies.cmake` and other in
`ANDROID_EXTRA_LIBS`.
Bug fix: find stl was dependent on the order in which libc++
was added, now it is independent.
Test Plan: * add the same dependency in ANDROID_EXTRA_LIBS
Reviewers: apol, vkrause
Reviewed By: apol
Subscribers: kde-buildsystem, kde-frameworks-devel
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D20509
|
|
|
|
Summary:
It turns out QT_STRICT_ITERATORS does not introduce any
overhead (they are inlined so everything gets optimized), confirmed by
Dan comparing the produced assembly in Compiler Explorer.
Reviewers: dvratil, mlaurent, aacid
Reviewed By: aacid
Subscribers: aacid, kde-buildsystem, kde-frameworks-devel
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D20349
|
|
Let's see if purpose unittests still work on Windows (which was the
reason this got commented out, kio_file wasn't found anymore).
CCMAIL: bcooksley@kde.org, kfunk@kde.org
|
|
Summary: Instead of passing the data from stdin, pass the path, this way if there's an error wayland-scanner will be able to tell us the file and line where it's failing.
Test Plan: Built kwayland and kwin with it
Reviewers: #kwin, #frameworks, zzag
Reviewed By: #kwin, zzag
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D20105
|
|
This reverts commit 2e1cb0c453f419da134b850052da6c804cae05e0.
This was an accidental push to master, sorry for the noise.
|