SUMMARY DrKonqi finds its available debuggers via `foorc` files in the location retrieved by QStandardPaths::locate(QStandardPaths::AppDataLocation, path, QStandardPaths::LocateDirectory) This means that the system profiles in $prefix/share/drkonqi/debuggers will be ignored if the user creates a ~/.local/share/drkonqi/debuggers directory (on regular Unix, read the corresponding paths on Mac and MSWin). I'm not entirely certain how bad this is, given that DrKonqi doesn't allow a choice of the debugger used to generate a crash report. It does mean that the built-in default will be used if the user leaves the directory empty, and that default might not be correct on a given install.
What is the problem? Also, what is a "built-in default"? Also, why would the *user* do anything to any directory pertaining to drkonqi debuggers?
> What is the problem? The user can break a distro- or install-specific configuration of the debugger backend, simply by creating an empty directory. > Also, what is a "built-in default"? A default (setting) that's hardcoded and used as a fallback. ``` DebuggerManager *KCrashBackend::constructDebuggerManager() { QList<Debugger> internalDebuggers = Debugger::availableInternalDebuggers(QStringLiteral("KCrash")); KConfigGroup config(KSharedConfig::openConfig(), "DrKonqi"); #if defined(__MAC_OS_X_VERSION_MAX_ALLOWED) && __MAC_OS_X_VERSION_MAX_ALLOWED > 1070 QString defaultDebuggerName = config.readEntry("Debugger", QStringLiteral("lldb")); #elif !defined(Q_OS_WIN) QString defaultDebuggerName = config.readEntry("Debugger", QStringLiteral("gdb")); #else QString defaultDebuggerName = config.readEntry("Debugger", QStringLiteral("cdb")); #endif ``` > Also, why would the *user* do anything to any directory pertaining to > drkonqi debuggers? S/he may want to select a specific lldb version (LLVM executables are typically installed with the major version appended to their name), a self-built gdb. S/he could also have symbol cache files that would speed up the backtrace generation. Even if the user is an admin s/he may still prefer to install the customised debugger profile in a personal and not a system-wide location - and in that case the profile should ideally be an addition to the system-defined profiles. When looking up resources in multi-valued QSP locations one would normally obtain the list of all possible locations and then check them in an additional loop.
(In reply to RJVB from comment #2) > > What is the problem? > > The user can break a distro- or install-specific configuration of the > debugger backend, simply by creating an empty directory. Please give a list of commands that demonstrate this.
Actually nevermind. I see the problem > QStandardPaths::locate(QStandardPaths::AppDataLocation, path, QStandardPaths::LocateDirectory) the lookup code in Debugger::availableDebuggers searches for one directory, when it should in fact look at all of them and assemble all debuggers from all dirs
(In reply to Harald Sitter from comment #4) > the lookup code in Debugger::availableDebuggers searches for one directory, > when it should in fact look at all of them and assemble all debuggers from > all dirs Yes, maybe I should have said explicitly that QSP::locate() returns the 1st hit; `QStandardPaths::locateAll()` should return the list of all matching files (or directories). Sorry, I thought this was common knowledge (it becomes that after you run into the difference a few times yourself ;))