do not inject SOURCEDIR and BUILDDIR into the environment of
build steps and run configurations any more.
instead, all custom executable paths, argument lists and working
directories now support the %{sourceDir} and %{buildDir} macros.
this approach is more elegant and more scalable.
get away from argument stringlists. instead, use native shell command
lines which support quoting/splitting, environment variable expansion
and redirections with well-understood semantics.
Task-number: QTCREATORBUG-542
Task-number: QTCREATORBUG-1564
this is a wrapper around QProcess with these features:
- setEnvironment() takes a Utils::Environment instead of a QStringList
- instead of taking a stringlist with arguments, take a single shell
command string which is fully compatible with the system's native
shell (the bourne shell on unix and cmd.exe on windows) - with support
for environment variable expansion, and subject to the shell's
splitting and quoting rules. if the command is too complex (e.g.,
contains redirections), it is transparently executed through a real
shell.
- additionally, the class contains a set of helper functions for
manipulating (constructing, splitting, etc.) shell command lines.
in particular, it contains a shell-safe macro expander and the nested
class ArgIterator which can be used for inspecting and manipulating a
shell command line without going through the stringlist indirection
(which is potentially lossy).
some of this is based on KDE code (KShell and KMacroExpander) which i
have written myself.
AbstractMacroExpander (any macros), AbstractQtcMacroExpander (%{var}
style macros, which is a hybrid of printf format specifiers and unix
environment expansions) and expandMacros() for the actual string
manipulation.
this is less confusing, because it doesn't look like an environment
variable expansion under unix.
the syntax is a hybrid of printf format specifiers and braced unix
variable expansions.
instead of being os-agnostic, interpret the os-native expansion style,
so it is consistent with proper (shell) command lines.
don't interpret quotes, as this function is meant for expanding isolated
filepaths, where nobody would expect quoting. instead, use the windows
style of simply not doing an expansion if a referenced variable is not
found, which should be good enough - it's rather unlikely that something
which happens to be an expansion of an existing variable is actually not
meant to be one.
A full evaluate() call resolves the property and continues to the
underlying type. If we use Evaluate::reference() instead, we only the
first step is done and we can get at the source location if a
ASTPropertyReference is returned.
Reviewed-by: Erik Verbruggen
Remove BreakHandler::hasPendingBreakpoints, handle new types
in CDB and gdb. Start fixing Breakpoint-Dialog.
Add assignment of Breakpointresponse from BreakpointParameters.
Reviewed-by: hjk
