https://bugs.kde.org/show_bug.cgi?id=409792
--- Comment #2 from RJVB <rjvber...@gmail.com> ---
> 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.
--
You are receiving this mail because:
You are watching all bug changes.
