kdebugsettings categories files
Details
Diff Detail
- Repository
- R240 Extra CMake Modules
- Branch
- add_specific_kdebugsetting_directory
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 12127 Build 12145: arc lint + arc unit
kde-modules/KDEInstallDirs.cmake | ||
---|---|---|
583–584 | KXMLGUI_INSTALL_DIR) came from this line :) |
Looks mostly fine safe for the directory name that needs the major version to avoid conflicts when libfoo.categories built using KF5 will have to coexist with KF6.
It needs a '5' in its name.
I'm also unsure about 'KDEBUGSETTINGSDIR'. kdebugsettings is the 'tool to change the debug messages visibility' and it makes it sound like we're still using kdebug :)
What about 'DEBUGCATEGORIESDIR' instead?
You didn't add "KXMLGUI_INSTALL_DIR)" back to where it belongs afaics.
If noone has a better suggestion, we'll go for debug-categories5
kde-modules/KDEInstallDirs.cmake | ||
---|---|---|
131 | Might LOGGINGCATEGORIESDIR or perhaps short LOGCATDIR not be a better name, for one more following the naming pattern of Qt, but also more clearly pointing out what this is about? Debug categories could mean a lot, while this here is about logging only. | |
132 | given this is adding a dir in the shared naming area, could this perhaps be more specific named, unless the plan is to make this a general-purpose dir shared among all kind of applications & toolkits? |
LOGGINGCATEGORIESDIR indeed it's more specific +1 for me
debug-categories5 => indeed it's just using by kdebugsettings at the moment. => kdebugsettings-categories5 ?
no idea if it's better.
@dfaure do you have an idea ?:)
My suggestion is to call this qlogging-categories5.
The 'q' prefix is missing to make this qt-specific rather than cross-toolkit.
The "logging" instead of "debug" is because this affects all types of messages, and this is all about what's called "logging categories" in Qt.
The "5" will allow co-installation of the qt5 and qt6 versions of the same library (but it will require two versions of kdebugsettings, or that kdebugsettings looks in both places -- but that can be done later).
I wouldn't name it after the application using this, because well, it could change name, and there could be more apps using this (e.g. akonadiconsole, kdevelop...).
kde-modules/KDEInstallDirs.cmake | ||
---|---|---|
132 | nitpick: s/qt/Qt/ |
Maybe also update the commit message to 'Create specific directory for Qt logging categories file'
This change appears to be responsible for all Android builds being broken.
See https://build.kde.org/view/Failing/
Could someone take a look please?
Seems the cause of the build failures is that with the Android builds not the ECM from the product builds or dep builds is picked up, but only the ECM as deployed as part of the SDK.
At least this is what looking at the age of the different builds on CI of the ECM product, the dep set and the SDK showed (where SDK was older than this change, everything else newer).
And triggering a fresh build of the SDK made the builds of the Framework products no longer fail.
So no issue with this patch, but the Android build setup it seems.
@apol @vkrause Perhaps something to check wit the CI or in general with the ECM Android toolchain to make sure the ECM of the host and the target are not accidentally mixed or both visible at the same time.
Right, I don't understand why it does that though. On binary factory we didn't have that problem, and AFAIK they use the same setup?
The Binary Factory uses the tooling shipped as part of the KDE SDK (which always builds everything from scratch, and I don't know if part of that includes ECM, hence why the issue doesn't show up there).
The CI system on the other hand uses it's own tooling exclusively on all platforms, however because the Android image ships with a limited number of libraries it is reliant on the KDE SDK to provide a number of non-KDE libraries, and thus has to include the SDK paths when performing builds. Unfortunately this means that it is possible on Android for CI builds to be contaminated by the SDK - the result of which we're seeing here.
Ideally the SDK would separate the base system (non-KDE) libraries from the KDE ones to avoid this issue (and the CI system could therefore rely on it's own build results exclusively)