| Age | Commit message (Collapse) | Author |
|---|
|
This doesn't make all these modules actually work with Qt6 yet, but it
prevents them from unconditionally pulling in Qt5 in a Qt6 build.
This is useful in order to even be able to pass a CMake run to the
point one can port, test and debug the rest.
|
|
- 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
|
|
|
|
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
|
