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

[Christian Gagneraud]

On Mon, 13 May 2019 at 05:27, Tobias Hunger <tobias.hunger at gmail.com> wrote:
>> 2. "Define Build System" page.
>> Currently the boiler plate attempt to identify the "Project type" to
>> generate, but doesn't rely/use the semantic of the
>> "supportedProjectType" above.
>> Instead they use the HasPlugin concept to map the build system tool
>> (aka, "qmake", "qbs", "cmake"), which is actually equivalent to the
>> project type (the wizard doesn't care about the tool, it cares about
>> the project manager it targets: CMakeProjectManager.CMakeProject,
>> Qbs.QbsProject, ...).
>
>
> Sure. Disable qmake and qbs support in Creator and see what happens:-)

!?!

What i'm trying to say here, is that for each project manager, the
wizard plays with 3 information, let's take qmake:
PluginId => QmakeProjectManager
ProjectTypeId => QmakeProjectManager.QmakeProject (as defined by the plugin)
BuildSystem => "qmake" (which could be "some random alias" since this
is internal to the wizard, and is just used to multiplex the
generator)

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.

What i'm proposing here, is to forget about these 3 facets, and use
only one way to talk about projects: The ProjectTypeId.
I do not care about the fact that 'QmakeProjectManager' plugin
provides 'QmakeProject', and that it uses "qmake" as a build system.
What i care, is that my JSON wizard can generate stuff for
ProjectTypeIdX, ProjectTypeIdY and ProjectTypeIdZ, all the rest is
implementation details.

Injected into wizard:
 - availableProjectTypes
 - parentProjectType (in case of sub-project)
Selected by user:
 - ProjectType (in case of top project, aka. %{BuildSystem})
Defined by wizard:
 - supportedProjectType
 - enabled = !intersection(availableProjectTypes,
supportedProjectType).isEmpty()

This would make the writing of project wizards IMHO more consistent,
but would require quite some changes, i agree with that.

And concerning the case "Sub project from main menu", Wouldn't it be
better to ask for the parent project on the first page, not the last
one?
Actually, maybe the first page should only be about project parenting
and build systems, since they are strongly coupled

>
> <snip>
>
>> 5. Ideas to achieve that
>> I did some quick hack in the ProjectNode, there is a "buildKey()"
>> there, that returns the build target key, so i added a
>> "projectTypeKey()" that returns the project manager's project ID
>> (CMakeProjectManager.CMakeProject, ...), and which is injected wizard
>> environment.
>
>
> That could help when starting the wizard via the context menu. That is unfortunately not the only way to trigger this wizard.

Yes, there are already variables that are only defined when started
via the context menu. we could add more, couldn't we?

>
>> With the above and proper macro nesting, it should be possible to
>> define the following wizard options:
>>  - IsSubProject, IsTopProject
>>  - HasCMake, HasQmake, HasQbs
>>
>>  - IsCMake, IsQmake, IsQbs
>
>
> Please do not hardcore the list of possible build systems! There are more plugins out there 5han those that are shipped with Creator.

I'm talking about the "options" section of a wizard, this information
is already hard coded into the wizard, the above list is just a
convenience naming sheme, eg:
options: [
 {key: "HasCMake", "value": "%{JS:
value('Plugins').indexof('CMakeProjectManager') >= 0}"},
 {key: "IsSubProject", value: "%{Exists:ProjectExplorer.Profile.Ids}"}
 {key: "IsTopProject", value: "%{JS: !value('IsSubProject')}"}
 ...
]

the IsQmakeProject, etc... case is a bit trickier, as there are 2 sub-cases:
- Triggered from main menu: User's choice if top project, parent's
project type in case of sub-project
- Triggered from context menu: injected by the project explorer (as
described above)

One last comments, sorry to sound negative, but currently all project
templates are a massive pile of copy/paste, with complex and error
prone macro/javascript expressions.
That is clearly a sign that something is "far from ideal".
I'm not moaning or anything, i'm really just trying to help this
wizard thing going. I can't wait to be able to do with qbs/cmake what
i can currently do only with qmake.

chris