[Qt-creator] QtCreator Plugin Dependencies

[André Pönitz]

On Tue, Oct 16, 2018 at 09:36:47PM +0200, Jochen Becher wrote:
> 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?

> 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'