* "In blah method " messages are informative, not errors.
* Be more picky about file names: Stops errors from ranlib, rm,
etc. being reported as build issues.
* Rework IBuildParser:
* Remove name() method.
* Remove enterDirectory and leaveDirectory signals.
* Allow chaining of parsers.
* Rename IBuildParser to IOutputParser.
* Implement GnuMakeParser.
* Remove entering/leaving directory related code from all other parsers
* Move filename fixup heuristic based on entering/leaving directory
massages from gnumake here from AbstractMakeStep.
* Add outputParser method to ToolChain: This removes the need to map
toolchains to BuildParser names in the BuildSteps.
* Enhance AbstractProcessStep to accept a IOutputParser to parse its output.
* Remove AbstractMakeStep.
* Set the appropriate Parsers in all classes deriving from AbstractProcessStep
and append the ToolChain's parser to the parser chain.
* Remove BuildParserFactories: There is no more need for them.
* Remove constants used to identify the BuildParsers.
* Clean up some names:
* Replace stdOut with stdOutput.
* Replace addToTaskWindow with addTask and addToOutputWindow with
addOutput. Do this wherever it is not yet clear that this will end up
in the Task/Output window.
Reviewed-by: dt
* Use Task class in addToTaskWindow(...) signal. This introduces
support for task categories into the BuildParsers.
* Add a task category for buildsystem issues.
* Update existing BuildParsers to new API and assign their
tasks to the Compile or Buildsystem task category.
Reviewed-By: dt
The category differs between e.g. TODO tasks, compiler errors/warnings,
qml syntax errrors ... Idea is that every plugin can manage it's
own virtual list of tasks.
Reviewed-by: dt
Details: This enables us to parse the build errors correctly.
The makesteps of the qt4project and cmakeproject have some
code dupliaction, which could be refactored. And the code
to find out the correct build parser could probably also
be done better, but we are now parsing the build output for
cmake.
