[Qt-creator] [heads-up] some changes in creator master

[Oswald Buddenhagen]

moin,

i just pushed some (below the surface) rather drastical changes to how
creator starts external processes, specifically the stuff from the build
and run configurations.


1) the most notable change is that every "arguments" field is now
interpreted according to the system's native shell (i.e., sh and cmd)
semantics. this has the advantage that we don't have to invent our own
quoting rules (or actually ignore the problem of arguments with spaces
entirely, as we did in several places). on the downside, windows users
have to deal with cmd quoting rules now - guess what "foo"^\""bar" means
:D. if creator finds that the command is too complex for its parser, it
will actually run it through a real shell. that means that you can have
redirections and similar goodies in there.

the thing still has some rough edges:

- debugging complex commands doesn't work at all under windows, and
  doesn't work in "run in terminal" mode under unix.
  
  this can be fixed by enhancing the qtcreator_process_stub to reproduce
  what gdb does under unix (start the command through a shell and guess
  when the shell starts the actual inferior process).

- while the argument lists are basically completely free-style shell
  command lines, the "executable" fields are still separate and thus
  always are the first element of a command. this looks just weird and
  precludes some more complex use cases (like piping some test data into
  the tested application or using command grouping).

  the obvious fix would seem to be just joining the various "executable"
  and "arguments" fields. but in some cases creator needs to know what
  the actual executable is or even determines it itself. in these cases
  the "arguments" field would be replaced with a "command" field which
  contains a macro like %{exe} to be expanded at execution time.

i'm not going to work on that anytime soon, so the tasks are up for
grabs.


2) creator won't inject the BUILDDIR and SOURCEDIR variables into the
environment of build steps any more. instead, the macros %{buildDir} and
%{sourceDir} can be used in the argument lists. fwiw, the macros take
care of quoting their expansions.
the macros also work in executable and working directory paths.


3) environment variable expansion syntax is not os-agnostic any more.
that's obvious for the argument lists (see 1), and was done for working
directories and executable paths as well for consistency. i didn't touch
the environment setup pages, but it should be changed at some point as
well.


i tried to provide automated upgrade paths, so you shouldn't need to
adjust existing configurations unless you rely on the environment
variable injection.


have fun