| Age | Commit message (Collapse) | Author |
|---|
|
|
|
use the CMake variable CMAKE_CROSSCOMPILING to detect when
cross-compiling instead of CMAKE_TOOLCHAIN_FILE.
CMAKE_TOOLCHAIN_FILE can be set when not cross-compiling
|
|
This was built with:
-DQT_MAJOR_VERSION=6 \
-DEXCLUDE_DEPRECATED_BEFORE_AND_AT=5.90.0 \
-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x055a00
Move the include(KDEInstallDirs) call before the first find_package(Qt*,
the former is what auto-detects the Qt version, and defaults to 5. This is
needed to be able to build against Qt5 by default.
All unit tests still pass.
|
|
NO_CHANGELOG
|
|
Summary:
The current KConfigXT compiler is in a sad state:
It's a massive file with loads of global variables that handle state, the generator is done within the main() function and it seems to have grown organically. There are no classes to separate logic / state / generation, what exists is code that generates code from a xml / ini pair, but it's hard to even discover what a bit of code is doing. The code istyle is C++ / Java from the nineties, which is not bad per see but it also uses quite a few things that are going to be deprecated in Qt 6 so I'm also taking the time make the code more streamlined with newer code style (no iterators, lambdas, auto usage, etc).
The code that generates the files simplly pushes strings to a text stream, and it's hard to figure out when something starts or something ends: for instance, the code that generates the Constructor has more than sixty lines of code englobing some nested if - for - if - for constructs.
Currently the code is "done" - there's one bug that I still need to find & fix regarding Translations, but the rest seems sane.
The current testcode generates incorrect *whitespaces* regarding the old code (there's some parts that I feel that it's important to fix before merging, but overall, the whitespace changes are not bad and easier to handle, old code had a hand-counted amount of spaces before each line, new code has a function whitespace() that adds the current-and-correct amount of whitespaces based on indentation level that you start by startScope() and ends with endScope(). rest of the code still needs to be ported to it.
I plan to fix the testcases whitespace by manually adding them, I'v fougth with the code for a while and added a few hacks there but I don't want to make the code hackish again.
New code is not perfect by any means, but is a good step in the right direction.
This code tries to Separate the compiler code into many different files / classes to be more obvious what's happening, and each class also has many helper methods to minimize copypaste.
- CodeGenerator: Has base code for the header and source files that can be shared
- HeaderGenerator: Logic for generating the header file
- SourceGenerator: Logic for generating the source file
- KcfgParser: Logic for parsing the kcfg file and extracting the information from the Xml file
- CommonStructs: a header that contains the structs that are currently used everywhere.
- KConfigParameters: (was CfgConfig - ConfigConfig, wat) - Has information passed via the kcfgc file
- kcfg_compiler - will be renamed to main - start the other classes and generates the files.
This code here currently has the begining of this separation, with the CodeGenerator and the HeaderGenerator in a ~good~ state, but unfinished.
Test Plan:
- Run the test cases,
- Compare the diffs generated by the testcases and fix in the code the errors / differences
- Run and compare real kde source with the new and old generators to look for errors
Reviewers: #frameworks, ervin, bport, dfaure
Reviewed By: dfaure
Subscribers: davidre, bcooksley, cgiboudeaux, kossebau, bport, ngraham, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D26202
|
|
This reverts commit 98c32e29f50465d4d4e16bafdf0491edbfb422b0.
This broke kdevelop and kmymoney. I'm workin on the fixes and more
unittests for them.
|
|
Summary:
The current KConfigXT compiler is in a sad state:
It's a massive file with loads of global variables that handle state, the generator is done within the main() function and it seems to have grown organically. There are no classes to separate logic / state / generation, what exists is code that generates code from a xml / ini pair, but it's hard to even discover what a bit of code is doing. The code istyle is C++ / Java from the nineties, which is not bad per see but it also uses quite a few things that are going to be deprecated in Qt 6 so I'm also taking the time make the code more streamlined with newer code style (no iterators, lambdas, auto usage, etc).
The code that generates the files simplly pushes strings to a text stream, and it's hard to figure out when something starts or something ends: for instance, the code that generates the Constructor has more than sixty lines of code englobing some nested if - for - if - for constructs.
Currently the code is "done" - there's one bug that I still need to find & fix regarding Translations, but the rest seems sane.
The current testcode generates incorrect *whitespaces* regarding the old code (there's some parts that I feel that it's important to fix before merging, but overall, the whitespace changes are not bad and easier to handle, old code had a hand-counted amount of spaces before each line, new code has a function whitespace() that adds the current-and-correct amount of whitespaces based on indentation level that you start by startScope() and ends with endScope(). rest of the code still needs to be ported to it.
I plan to fix the testcases whitespace by manually adding them, I'v fougth with the code for a while and added a few hacks there but I don't want to make the code hackish again.
New code is not perfect by any means, but is a good step in the right direction.
This code tries to Separate the compiler code into many different files / classes to be more obvious what's happening, and each class also has many helper methods to minimize copypaste.
- CodeGenerator: Has base code for the header and source files that can be shared
- HeaderGenerator: Logic for generating the header file
- SourceGenerator: Logic for generating the source file
- KcfgParser: Logic for parsing the kcfg file and extracting the information from the Xml file
- CommonStructs: a header that contains the structs that are currently used everywhere.
- KConfigParameters: (was CfgConfig - ConfigConfig, wat) - Has information passed via the kcfgc file
- kcfg_compiler - will be renamed to main - start the other classes and generates the files.
This code here currently has the begining of this separation, with the CodeGenerator and the HeaderGenerator in a ~good~ state, but unfinished.
Test Plan:
- Run the test cases,
- Compare the diffs generated by the testcases and fix in the code the errors / differences
- Run and compare real kde source with the new and old generators to look for errors
Reviewers: #frameworks, ervin, bport, dfaure
Reviewed By: dfaure
Subscribers: bport, ngraham, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D26202
|
|
Summary:
This is particularly useful for cross-compilation, where we only need the
kconfig_compiler on the host system.
Reviewers: #frameworks, apol, aacid
Reviewed By: aacid
Subscribers: aacid
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D6994
|
|
Makes sure that it doens't create an app bundle on Mac OS X
REVIEW: 125337
|
|
|
|
As recommended by Alex Merry
CCMAIL: alex.merry@kde.org
|
|
This will make it end up in a platform-dependent prefix (i.e. /usr/lib64,
/usr/lib/arm-linux-gnueabihf, etc) rather than /usr/bin, making it possible
to have different kconfig_compiler versions installed, useful for
cross-compilation.
REVIEW: 124138
|
|
This way we can specify the used tooling targets to be used, useful if we're
cross-compiling, since we get to use the tooling that runs in the local
platform.
REVIEW: 124104
|
|
This is instead of INCLUDE_INSTALL_DIR and INSTALL_TARGETS_DEFAULT_ARGS,
which will lose the "KF5" suffix from the include path.
|
|
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
|
|
These lines of code do not really require any justification.
REVIEW: 116962
|
|
|
|
|
