Age | Commit message (Collapse) | Author |
|
AUTOMOC now applies to generated headers too, so we need to skip it
when using qt5_generate_moc.
|
|
Summary: Show a warning together with the old broken behavior
Reviewers: #frameworks, dfaure
Reviewed By: dfaure
Differential Revision: https://phabricator.kde.org/D3287
|
|
Summary:
Use cmake_parse_arguments() instead of roughly implementing it locally
CCBUG: 371562
Test Plan: recompiled everything, nothing broke
Reviewers: #frameworks, dfaure
Reviewed By: dfaure
Differential Revision: https://phabricator.kde.org/D3251
|
|
Summary:
Fallback on trying the same filename as the actual file.
There were some regressions due to the former matching expression:
string(REGEX REPLACE "^(.*\n)?File=([^\n]+kcfg).*\n.*$" "\\2" _kcfg_FILENAME "${_contents}")
This one would allow for the File field to be the kcfgc file (which doesn't
make sense).
With this patch we're not reproducing this behaviour, but we're allowing for the
things that aren't building to work. After all, most kcfg and kcfgc files share
the same name.
Reviewers: #frameworks, davidedmundson
Reviewed By: davidedmundson
Subscribers: aacid, kfunk
Differential Revision: https://phabricator.kde.org/D3226
|
|
Summary:
Instead of having an odd fake of it. Will help some required
refactorings and already showed some issues, fixed by this patch,
namely:
- don't use string(regex replace) to extract a string from another
string. in case it doesn't match it will offer the whole content which
is never what we want.
- messages(ERROR), the correct parameter is FATAL_ERROR, cmake
understands "ERROR" as mere output string
- turn the macro into a function, otherwise 2 calls in the same
subdirectory are dangerous.
CCBUG: 371562
Test Plan: tests still pass, projects that use the macro still build
Reviewers: #frameworks, dfaure
Reviewed By: dfaure
Subscribers: dfaure
Differential Revision: https://phabricator.kde.org/D3178
|
|
|
|
Just because the executable has the "_kf5" suffix, that does not mean
the target should have it. This is ugly API, and will be unnecessary
porting effort for KF6.
REVIEW: 116995
|
|
Not sure why it would be unset and then used, instead of just not used
at all. LXR says it's not used anywhere else, though.
REVIEW: 116962
|
|
|
|
|