| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Summary: Use QT_NO_NARROWING_CONVERSIONS_IN_CONNECT as default flags
Reviewers: dfaure
Reviewed By: dfaure
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D15566
|
|
|
|
This reverts commit 6684cb99bdf408fc491e547393dbd7aac4d151f2.
See https://phabricator.kde.org/D8256 for details
|
|
When building on non-glibc Unix platforms, such as Solaris, NetBSD, and Linux/musl or Linux/uclibc, multiple components of KF5 fail to build. This is because -std=iso9899:1990 is specified (for strict C90 compliance) but _XOPEN_SOURCE is not defined, so none of the POSIX interfaces are exported. I have seen this reported in at least:
* kinit
* kscreenlocker
* plasma-workspace
The attached patch resolves this issue on all our build boxes; additionally, applying it to my glibc builder did not change the already working result.
BUG: 373175
Differential Revision: https://phabricator.kde.org/D8256
|
|
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
|
|
Summary:
QT_USE_FAST_OPERATOR_PLUS has been deprecated in Qt 4.8, in favour of
QT_USE_QSTRINGBUILDER. The latter also covers QByteArray.
Qt5 headers still supports QT_USE_FAST_OPERATOR_PLUS (at least 5.11.1),
as subset of QT_USE_QSTRINGBUILDER as it was introduced in Qt4.8,
but not as documented build flag.
Given QT_USE_QSTRINGBUILDER is set here and thus triggers anything that
QT_USE_FAST_OPERATOR_PLUS would trigger in Qt code, removing it should
clean up the macro from undocumented features and thus reduce confusion.
No non-Qt is known at least in KDE repos which checks this build flag
otherwise, so no regression should be expected here as well.
Reviewers: vkrause
Reviewed By: vkrause
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D13800
|
|
Reviewers: cgiboudeaux, apol
Reviewed By: cgiboudeaux, apol
Subscribers: apol, kde-frameworks-devel, kde-buildsystem, cgiboudeaux, dhaumann
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D10166
|
|
Summary:
It's not a thing on flatpak and it makes packaging weird.
Should fix https://github.com/flatpak/freedesktop-sdk-base/issues/22
Reviewers: #frameworks, cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: cgiboudeaux, eszlari, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D13102
|
|
Summary:
Otherwise we hit a weird code path on androiddeployqt. This is what the official SDK looks like anyway:
```
$ ls /opt/Qt/5.10.1/android_armv7/
bin doc include jar lib mkspecs plugins qml src translations
```
Reviewers: vkrause
Reviewed By: vkrause
Subscribers: #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D12269
|
|
Summary:
We already have rpaths anyway and it breaks running applications from
within the build directory:
https://community.kde.org/Guidelines_and_HOWTOs/Making_apps_run_uninstalled
Reviewers: #frameworks, dfaure, ngraham, graesslin
Reviewed By: ngraham, graesslin
Subscribers: graesslin, ngraham, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D9550
|
|
Summary:
If enabled it will install a prefix.sh script to the root of the prefix.
This file will be useful to be able to easily set up a prefix to be used by
integrating the environment variables it exports.
Test Plan:
```
$ cat prefix.sh
export PATH=/home/apol/devel/kde5/bin:$PATH
export LD_LIBRARY_PATH=/home/apol/devel/kde5/lib64:$LD_LIBRARY_PATH
export XDG_DATA_DIRS=/home/apol/devel/kde5/share:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}
export XDG_CONFIG_DIRS=/home/apol/devel/kde5/etc/xdg:${XDG_CONFIG_DIRS:-/etc/xdg}
export QT_PLUGIN_PATH=/home/apol/devel/kde5/lib64/plugins:$QT_PLUGIN_PATH
export QML2_IMPORT_PATH=/home/apol/devel/kde5/lib64/qml:$QML2_IMPORT_PATH
```
Reviewers: #frameworks, sitter
Reviewed By: sitter
Subscribers: kfunk, bcooksley, ngraham, sitter, cgiboudeaux, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D9299
|
|
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:
when KDE_INSTALL_USE_QT_SYS_PATHS has been explicitely set,
qmake can be considered a required dependency, otherwise the
paths will not be known, which would be unexpected.
Also does the code calling query_qmake, besides the one testing
for the same install prefix, not handle the case of empty strings
being returned and then results in bogus behaviour.
Thus this patch makes code fail hard if query_qmake is expected
to yield a result, but no qmake executable is found.
Reviewers: #frameworks, ltoscano, rdieter, apol
Reviewed By: apol
Subscribers: #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D6772
|
|
Reviewers: #frameworks, apol
Reviewed By: apol
Subscribers: #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D6773
|
|
Differential Revision: https://phabricator.kde.org/D6762
|
|
|
|
Mea culpa, the project I tested this with apparently used the macro too.
|
|
Don't attempt to guess whether (Apple) Clang 3.5 supports -Wdate-time,
use CheckCXXCompilerFlag and be certain.
|
|
This modifies 340b969f54d2f271e925ed7f84c831e1e4b2ccd0 by testing for
Xcode <= 6.2 using the AppleClang version scheme only, to account for
rare conditions where the compiler ID is not AppleClang.
|
|
Summary:
Enables generation of QCH files during a normal build,
for documenting the public API of a library.
These macros are especially done with release builds in mind,
so distributed packages (like from Linux distributions) can
include QCH files matching the version of the library and will be
also automatically updated on new versions of the libary.
Next to that these macros also support linking between different
QCH files, so a subclass from another library for which there also
is a QCH file installed will be linked to the entry in that other
QCH file.
This inter-QCH linking is especially useful for libraries extending Qt,
where many of the used types are from Qt libraries. The macros
come with the needed information for Qt libraries prepared, so the
used Qt libraries just need to be listed in the LINK_QCHS argument
by target names, like Qt5Core_QCH or Qt5Widgets_QCH.
This should be a nice supplement to online services like api.kde.org,
like Qt's own QCH files are to doc.qt.io,
While QCH files from an abstract POV could be seen similar to code
libraries, being components with links to lookup symbols/entries in
other QCH files, so the rules and code should be done with similar
concepts, currently CMake's target system seems bound to executable
code creation. So things like "file(EXPORT ...)" could sadly not be
reused, as custom targets are not supported with that.
Thus a custom macro had to be created for now. Also could I not find
a way to use namespaces like KF5::, for more consistent target naming.
The patch also adds two variables to KDEInstallDirs.cmake for
controlling where the QCH (and respective doxygen tag files) are
installed. The QTQCHDIR variant allows to install QCH files for
Qt-extending libraries into the same folder where Qt's own QCH
files are, so Qt Assistant & other QCH viewer pick up them automatically
to add them to the default help file collection.
The QCHDIR variant would provide a neutral, but central installation
location. Neutral, as it never "pollutes" the Qt system dirs with files
possibly unrelated to Qt-based development (e.g. when simply using qthelp
tools for documentation), and central, to help with finding available QCH
files for manually adding/loading them into a viewer, given there is no
official way currently to register the availability of QCH files on
installing.
Open questions:
a) target system for exporting/importing done in a sane way?
Better name pattern for the QCH targets than xxx_QCH
(see the targets created for Qt, like Qt5Core_QCH)?
b) sharing metadata with kapidox
Initially I placed these macros into the kapidox module, as this seems the
logic place. And would match what kdoctools does for user manuals.
Just, that would create a build dependency on kapidox which complicates usage
a little. Having these macros in ECM delivers them with no extra effort
needed.
The data in metainfo.yaml is partially duplicated with the data feed into
the macros. How to deduplicate that is still open. Especially with the need
to not depend on external data sources like identify.kde.org.
Issues:
* doxygen versions before 1.8.13 are broken and miss to include some files
with generated QCH (https://bugzilla.gnome.org/show_bug.cgi?id=773693)
* Qt Assistant often only built with QTextBrowser, while doxygen uses lots
of HTML5 (incl. hardcoded JavaScript)
(https://bugzilla.gnome.org/show_bug.cgi?id=773715),
needs e.g. distributions to use QtWebKit to work, upcoming Qt versions
might soon also have QtWebEngine based help viewer
(https://codereview.qt-project.org/#/c/111559/)
* inter-QCH links do not work in KDevelop currently
(see https://bugs.kde.org/show_bug.cgi?id=372747) if installed as
separate QCH files
More details/background info at
https://frinring.wordpress.com/2016/09/27/adding-api-dox-generation-to-the-build-by-cmake-macros/
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D2854
|
|
Xcode 6.2 (OS X 10.9.5) has a Clang version that is based on Clang 3.5 but does
not yet support -Wdate-time . Commit 7af9f8e2b6eb235923a329e8ff24012883fb6b86
introduced a regression where this compiler failed to pass the visibility tests
because it prints a warning about -Wdate-time. This in turn leads to linker
errors.
|
|
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:
-Wvla: Warn because it's non-standard feature, not supported by MSVC to date
-Wdate-time: Warn because using __TIME__ or __DATE__ prevents reproducible builds
These warnings are being used for *building* Qt itself as well (cf.
qt_common.prf in qtbase)
Test Plan: No new warnings from rebuilding KDE Frameworks
Reviewers: mpyne
Reviewed By: mpyne
Subscribers: mpyne, #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5430
|
|
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:
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
|
