[Qt-creator] QtCreator Plugin Dependencies

[Jochen Becher]

Hi,

working on new features for ModelEditor I learned that some plugins
have bidirectional dependencies.

For example CppTools uses ProjectExplorer a lot but ProjectExplorer
uses CppTools only a little bit (for the two constants
CPP_SOURCE_MIMETYPE and CPP_HEADER_MIMETYPE). Moving these constant
definitions to some extra location or into ProjectExplorer would solve
this design flaw (at least I understand bidirectional plugin
dependencies as such).

What do you think about these kind of refactorings? How far would you
go to solve bidirectional dependencies, e.g. move code to a common
static lib or use an interface or signal/slots for dependency reversal?

Regards, Jochen

[André Pönitz]

Post by Jochen Becher
Hi,
working on new features for ModelEditor I learned that some plugins
have bidirectional dependencies.
For example CppTools uses ProjectExplorer a lot but ProjectExplorer
uses CppTools only a little bit (for the two constants
CPP_SOURCE_MIMETYPE and CPP_HEADER_MIMETYPE).
Moving these constant
definitions to some extra location or into ProjectExplorer would solve
this design flaw (at least I understand bidirectional plugin
dependencies as such).

git blame on projectexplorerconstants.h yields

5a6c76a1186 (hjk 2011-09-02 13:19:50 +0200 95) const char CPP_SOURCE_MIMETYPE[] = "text/x-c++src";
5a6c76a1186 (hjk 2011-09-02 13:19:50 +0200 96) const char CPP_HEADER_MIMETYPE[] = "text/x-c++hdr";

Isn't that what you ask for? I.e. the constants are "central" already?

Post by Jochen Becher
That's a "weak" compile time dependency (only headers, no linking)
What do you think about these kind of refactorings? How far would you
go to solve bidirectional dependencies, e.g. move code to a common
static lib or use an interface or signal/slots for dependency reversal?

Generally ok from my side, as long as a solution is not overly ugly
or expensive.

The problem as such does not have a good solution. Ideally one would e.g.
have all target platform plugins (desktop, rl, android, ios, qnx, baremetal,
...) be independent of each tool plugin (debugger, qml profiler, valgrind,
...), but they need to "communicate" somehow, even if that is only a "target
X supports tool Y" fact. This "cross" knowledge needs to live somewhere,
and neither targets nor tool plugins are a good place for it.

Pulling in a constant from a "sibling" plugin header within the base modules
(qt-creator.git) is currently considered "not nice, but tolerable".

Andre'