[Qt-creator] JSON wizard: build systems and sub-projects

[Christian Gagneraud]

On Mon, 13 May 2019 at 20:55, Tobias Hunger <Tobias.Hunger at qt.io> wrote:
>
> Hi Christian,
>
> reading my last mail again it was rather short and sounds harsher than intended.
> Sorry for that. I did not intend to slight you or your work, it is just that I
> get very lazy when composing mails on my phone.

I never felt offended or whatever. I tend to be short and sharp and
I'm too impatient sometimes.

> On Mon, 2019-05-13 at 10:38 +1200, Christian Gagneraud wrote:
> > On Mon, 13 May 2019 at 05:27, Tobias Hunger <tobias.hunger at gmail.com> wrote:
> I wanted to point out that the wizard has a hard-coded list of project types it
> supports. Creator also has a list of build systems it supports, which is dynamic
> and depends on the plugins that are loaded.
>
> At the "Define Build System" page that dynamic part is the important one: The
> wizard should not offer build systems that are not supported by the current
> Creator instance, even though it would support these build systems in other
> creator instances.
>
> So IMHO the wizard does the right thing here by relying on the loaded plugins
> and not on the supportedProjectTypes.

I might be wrong, but maybe you're into your generic world where every
kind of plugin can offer every kind of feature.
I'm a bit more pragmatic, all that I see is that there is a one to one
relationship b/w the project managers, their project type and their
underlying build systems.
QmakeProjectManager plugin -> QmakeProjectManager.QmakeProject project
-> "qmake" build tool
QbsProjectManager plugin -> QbsProjectManager.QbsProject project ->
"qbs" build tool
CMakeProjectManager plugin -> CMakeProjectManager.CMakeProject project
-> "cmake" build tool

These 3 combinations are the only valid ones out of a 3x3x3 permutations.

I haven't look into the other ones, autotools, bare metal, ...

I'm fine with giving up this idea, you guys know your tool more than I
do. I'm not familiar enough with the code base.

> > Currently JSON wizards for subprojects are not working, only the
> > built-in qmake one work (and AFAIU they need to go).
> > So something has to be done to solve this issue.
>
> I am aware of that and appreciate you looking into this problem.
>
> This will need more than just the wizard part to work though. E.g. CMake has no
> way to add new files into existing CMakeLists.txt files, so a wizard will not be
> able to do much in that case.

Troll Detector: WARNING! WARNING!

Well, so be it! We shouldn't hold qmake and qbs b/c cmake is inferior

Troll Detector: All Clear!

I'm sure the cmake guys will come with a solution later on, in the
mean time: let's move on.
If a particular project template only support Qbs and Qmake, it just
needs to declare it in it's supportedProjectType/enable properties,
isn't it how it is supposed to work? :)

> > What i'm proposing here, is to forget about these 3 facets, and use
> > only one way to talk about projects: The ProjectTypeId.
>
> I got that.
>
> But you will need to check whether a plugin is currently loaded and you will
> need to have a user-visible name for that build system and you need the. Where
> do you get that information from?
>
> Do you offer a registry in one of the plugins to hold that information
> somewhere?

availableProjectTypes and parentProjectTypes (when applicable) are the
user-visible project-type *providers*.

In my ideal world, i do not care about plugin loaded or not, if a
plugin is not loaded, it's associated project type is not available.
Is this a correct assumption?

Then, the "registry" is actually implicit, all the json wizards
already hard-code all of these:
 - plugin names (CMakeProjectManager, ...)
 - plugin namespace'd project types (QmakeProjectManager.QmakeProject)
 - local namespace'd build tools (qbs, ...)

Again, i might be wrong.

Maybe i should come with an ideal subdirs.json and discuss how realistic it is.

Chris