To overcome limitations and/or bugs of the toolchain and/or project managers in Qt Creator one wants to provide additional flags to clang. This is more important today than ever because of the Clang Code Model.
The most prominent example being here is Generic Project manager used to import projects. It basically allows to specify only a list of files, defines and include paths. While that was fine for the built-in code model, that's completely insufficient for the Clang Code Model.
For example, the option -fsized-deallocation affects the parser but it's not forwarded to the code model and error diagnostics will be emitted, which might affect also tidy checks, e.g. the clang static analyzer checks.
In earlier versions of Qt Creator it was possible to add random options to the "Diagnostic Configuration" and this was misused to overcome the problem.
Currently the run time environment variables QTC_CLANG_CCM_CMD_PREPEND and QTC_CLANG_CCM_CMD_APPEND are evaluated for a string to prepend or append to the command line. This affects every translation unit and is also not bound to a specific project. Because of this, using the environment variables might help for one (part of the) project, but make it worse for another (part). Also, 99% of the users don't know about the existence of these run time variables.
- Should we add an UI at all?
- Do we have here an option at all? If the project manager just can't access the command line flags of the build system, what other options do we have? --> We can't rely on a Compilation Database as not all build systems generate one (yet?).
- If yes, how fine-grained should it be? (per project, per project part?)
Note that the Generic Project shouldn't be the reference or main reason for this. Personally I tend to deprecate it as probably every other build system Qt Creator supports is a super set of it with more fine-grained control.
Note also that we probably want to read a Compilation Database in future. By editing that file, the user could provide his own arguments on a per-file basis. However, on the next build that one is overwritten again.