| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
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
|
|
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
|
|
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:
Note that the first test had a comment "without optional arguments"
so I removed the INCLUDE_INSTALL_DIR variable to test what happens by
default. The other tests still pass an absolute path there (which is
unusual in practice, and breaks the idea of using ${prefix}).
Test Plan: `ctest -R PkgConfig` passes
Reviewers: kossebau, apol, cgiboudeaux
Reviewed By: apol
Subscribers: kde-frameworks-devel, kde-buildsystem, fazevedo
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D19538
|
|
GIT_SILENT
|
|
Summary:
If we ever end up in a situation where the generated .pc file is
actually used by cmake's pkg_check_modules, then we need the
includedir and libdir variables; pkg_check_modules ignores the
Makefile-like Libs and Cflags lines of the .pc file.
Context: craft adds a cmake buildsystem for sqlite3, which is then
found using pkgconfig in akonadi.
Test Plan: Filipe Azevedo is doing all the testing, I'm just providing patches :)
Reviewers: apol, fazevedo, cgiboudeaux
Reviewed By: fazevedo, cgiboudeaux
Subscribers: cgiboudeaux, fazevedo, kde-buildsystem, kde-frameworks-devel
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D19506
|
|
Summary: Also place "Since" next to both argument and argument description.
Reviewers: cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D18913
|
|
Summary:
Patch by Eike Ziller from https://github.com/KDAB/GammaRay/pull/526 in
response to Qt change https://codereview.qt-project.org/#/c/248684/.
Reviewers: apol
Reviewed By: apol
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D18243
|
|
|
|
|
|
|
|
This is for compatibility with Apple's Xcode
compilers which identify as AppleClang.
Differential Revision: https://phabricator.kde.org/D16816
|
|
|
|
Summary:
easier to read with spaces
SCM_SILENT
Reviewers: apol
Reviewed By: apol
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D16221
|
|
|
|
Summary: Use a similar strategy as D14528 to find qm files.
Test Plan: Analitza parts of KAlgebra are translated too.
Reviewers: #frameworks, aacid
Reviewed By: aacid
Subscribers: svuorela, aacid, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D14529
|
|
|
|
On Windows at least this is simply broken and leads to tests failing because plugins from other modules cannot be found at all.
Based on this it is likely that it is broken on other platforms as well, it's just being hidden there by other logic.
CCMAIL: kde-frameworks-devel@kde.org
|
|
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
|
|
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D14541
|
|
These changes are not available in ECM 5.48.0.
|
|
Summary:
- Add support for SIDEBAR_ICONS on macOS
- Allow specifying a basename for the icon file via OUTFILE_BASENAME
- Add support for HiRes icons on Windows via icotool
I'm sorry this went all into one big change. I see that it's not optimal,
but it's really hard to rip it apart...
Also to me the whole code with support for two flavors of png2ico and icotool seems very spaghetti-ish. IMHO there's no good reason to keep supporting all three, icotool is the only maintained project and the only one supporting more than 128px wide icons. That's why I would suggest to simplify the whole code by only supporting icotool in one of the next releases.
Test Plan:
We use this version of ECMAddAppIconMacro in ownCloud client and it works...
I tested icotool natively and while cross-compiling on linux.
SIDEBAR_ICONS are also working...
If you want to test this with the ownCloud client, it's best to use
https://github.com/dschmidt/owncloud-client/tree/fix-app-icon-macro
because that contains a small fix I just PR'ed and which is not
in master yet. (We maintain a fork of the module there, so compiling it for Windows or macOS will automatically use the version of the module that I'm submitting)
Reviewers: vonreth, vpinon, apol, alexmerry, cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: cgiboudeaux, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D13698
|
|
Summary:
Quite some C++-based projects do not use .h as header file extension, but
.hpp, .hxx or other variants. Making the header file extension configurable
enables to make use of ECMGenerateHeaders in such projects.
Test Plan:
The added unit test works, existing unit tests work as before.
Also using in project with .hpp files works.
Reviewers: apol
Reviewed By: apol
Subscribers: apol, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D13721
|
|
Summary:
These typos show up in the generated manpages.
Reviewers: #frameworks, alexmerry, kossebau, cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: cgiboudeaux, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D12867
|
|
|
|
Summary:
This macro helps with setting up all the boilerplate CMake code needed
to instruct automoc about the custom C++ macros used to define Qt-style
plugin class instances.
Reviewers: #build_system, #frameworks, apol
Reviewed By: apol
Subscribers: apol
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D10749
|
|
|
|
Summary: Without any hint, qmlplugindump version is whatever default is set by qtchooser.
Test Plan: ecm_find_qmlmodule now works properly for e.g. kirigami.
Reviewers: apol, cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: aacid, dfaure, cgiboudeaux, #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D9116
|
|
For locales like de_AT, the current code only looks in
share/locale/de_AT/ and share/locale/de-AT/ for translation catalogs,
but not in share/locale/de/ where they most likely are.
That's because bcp47Name() returns "de-AT" for de_AT (though in the
case of de_DE e.g. it does return "de").
This patch additionally tries to fall back to the general language by
taking the part of the locale name before the first '_'.
Differential Revision: https://phabricator.kde.org/D9793
|
|
Summary:
pkgconfig complains when the .pc file doesn't have a description. eg:
$ pkg-config Baloo
Package 'Baloo' has no Description: field
With this change, if the DESCRIPTION parameter is not used,
ECM_GENERATE_PKGCONFIG_FILE will :
- First look if there's a metainfo.yaml file and get the description from there
- If the file doesn't exist, or if the description tag is empty or non-existent,
create a description based on the LIB_NAME value
Test Plan: Tests added & pass
Reviewers: dfaure, apol
Reviewed By: dfaure
Subscribers: #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D9056
|
|
Summary:
We need to separate paths in environment variables
with a semincolon (;) on Windows.
Reviewers: dfaure
Subscribers: #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D8979
|
|
Summary:
This of course requires running the unittests via ctest rather than
launching the executable directly.
Test Plan:
`ctest -V -R kurifiltertest` in kio, which prints QCoreApplication::libraryPaths() at the beginning of the test.
With this commit, builddir/kio/bin is added at the front of the list, and the kurifilter plugins from kio's build are loaded.
Reviewers: cgiboudeaux, kfunk
Reviewed By: cgiboudeaux
Subscribers: #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D8660
|
|
This broke a lot of frameworks when built WITH BUILD_TESTING=OFF. I
didn't notice before since kdesrc-build was appending BUILD_TESTING=TRUE
thus re-enabling the tests for me...
This reverts commit b99d2d2c5dedcaba9745dddc1dd7b8d4811babf1.
|
|
Needed to revert parent commit
This reverts commit ebbef5afcaee863c62136b14dbd06a7a73cf769a.
|
|
Summary:
Allows to check if a module is available on the system and sets it as a
runtime dependency.
This is useful for projects so that they can specify their qml dependencies
easily and packagers and developers get to see what's missing by looking
at the cmake output.
Reviewers: #build_system, #frameworks, sitter
Reviewed By: sitter
Subscribers: dfaure, aacid
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D7094
|
|
|
|
Summary:
Use-case: Make building unit tests optional, by just following the CMake
BUILD_TESTING option.
The usual approach to conditionally build tests is to do:
```
if (BUILD_TESTING)
add_executable(TestOne TestOne.cpp)
target_link_libraries(TestOne my_library)
endif()
```
or:
```
if (BUILD_TESTING)
add_subdirectory(tests)
endif()
```
This patch just turns all calls to ecm_add_test(...) into no-ops if
BUILD_TESTING=OFF.
See:
https://cmake.org/cmake/help/v3.6/module/CTest.html
Reviewers: vkrause
Reviewed By: vkrause
Subscribers: kossebau, vkrause, elvisangelaccio, asturmlechner, apol, #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D7187
|
|
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
|
|
|
|
Cmp. https://bugzilla.gnome.org/show_bug.cgi?id=783759
|
|
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
|
|
Summary:
The old guard was created just from the identifier + _H, which runs the
chance to clash in projects which use an identifier matching the project
name and which also have a class or central file header which is named
by the project and then has an include guard matching the filename.
Example:
project ABC -> abc.h with ABC_H guard
identifier ABC, header debug.h -> debug.h with ABC_H guard
any.cpp including both abc.h and debug.h will see only one content
Using both the header file name and identifier for the guard name
and prefixing it additionally with a macro specific term should make
the guard both follow the usual pattern for guards matching the
file name and also add some namespacing to allow for similar named
header files in bigger projects (e.g. "debug.h") which could be
included in the same include tree.
Reviewers: #frameworks, #build_system
Subscribers: elvisangelaccio
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5866
|
|
Reviewers: #frameworks, #build_system, apol
Reviewed By: apol
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5867
|
|
Summary:
FreeBSD, opposed to most other sytems, does not install pkgconfig files to
lib/pkgconfig, but to libdata/pkgconfig.
Reviewers: #freebsd, apol, kfunk
Reviewed By: kfunk
Subscribers: kfunk, #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5766
|
|
Summary:
Fixes compiler warnings such as:
```
cl : Command line warning D9002 : ignoring unknown option
'-fsanitize=address'
cl : Command line warning D9002 : ignoring unknown option
'-fno-omit-frame-pointer'
```
Reviewers: aacid, bcooksley
Reviewed By: aacid, bcooksley
Subscribers: #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5489
|
|
|
|
|
