-
hjk authored
The change is "conceptually wrong", the AnalyzerRunControl derived classes' functionality should be provided by ToolRunners based classes encapsulating/"being" the current Analyzer*Runner classes. However, the AnalyzerRunControl is only three (empty even) virtual functions, but a big obstacle in merging attempt due to a lot of mechanical followup changes in downstream users. The current construction mechanism of analyzer run controls is actually two different mechanisms (locally direct RunControlFactories, and a "generic" createAnalyzerRunControl wrapper for remote cases). The generic createAnalyzerRunControl makes it difficult to migrated them one-by-one, due to the various downstream users. So instead of merging the per-analyzer two uses directly reduce the "indirection" distance by removing the AnalyzerRunControl intermediate layer. After that the createAnalyzerRunControl mechanism can be dissolved by using normal RunControlFactories also for the remote cases. After that, porting to ToolRunner, and combining with ther local equivalent can be done one by one. Change-Id: I0ddace33fcce210cf3a547ac5bb23b3d85013934 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
112e3222