[Qt-creator] Custom wizard vs qmake's wizards

[André Pönitz]

Christian Gagneraud <chgans at gmail.com> wrote:
> On Mon, 29 Apr 2019 at 21:50, Eike Ziller <Eike.Ziller at qt.io> wrote:
> > >> Actually, I just saw the supportsAction in the project node. That's a good
> > >> start. But there doesn't seem to be anything generic to handle adding
> > >> library, etc....
> > >> Maybe it's not hard to add, maybe not...
> >
> > That might be the way to go, but I also can’t really tell how much work that 
>  > would be. E.g. would it make sense to share (parts of) the actual wizard?
> 
> Well, maybe the project explorer shouldn't bother about implementation
> details of the underlying project managers.
> Why hard-code the concept of sub-projects, library, plugin, unit test,
> file, project, non-qt project, ... into the project explorer?

Because the concepts are independent of the build system.

Not handling that globally leads to multiple instances of the same
kind of code in each of the project manager which tend to develop life
of their own (bugs being noticed in one, fixed there, but present
and not fixed in others). That solution does not scale in practice.

> Or even hard-code the qmake view of what a "library" is (internal,
> external, system and pkg-config).
> Both Qbs and CMake have different view of this and they handle that in
> a better way.

Not on a conceptual level. Some names, parameters, or exact procedures 
might be different, but at the end of the day a library is a library, no matter
what build system created it. 

> project explorer attempts to dictate hard abstraction concepts,

It doesn't dictate that. If there's a need to add a build system specific
features, suitable callback/virtual function/property/whatever can 
be added on demand. 

> you risk to end up will all supported build systems being limited 
> (least common denominator).

That risk is manageable by looking for (and finding) abstraction on
the right level, and it doesn't have to be common denominator.

Andre'