[qt5-base] Move 'gui' and 'icu' out of 'core' feature

[dg0yt]

• What does your PR fix?

  This PR creates separate gui and icu features, reducing the number of dependencies and the build time for the core feature.

  • Adds an icu opt-in feature, reducing build time and deployment size of the default configuration. (It might make sense to leave it as a default feature to avoid a change for currents users.)
  • Adds a gui opt-out feature to qt5-base and qt5-tools, meant to benefit cross builds which have a host dependency on qt5-base[core] or qt5-tools[core]. (This PR is separated out of work to fix building qt5 for mingw, but android and other triplets might benefit as well.)
  • Adds a quick opt-out feature to qt5-declarative, meant to benefit users which only need Qt Widgets, not Qt Quick.

  In addition, there is some minor cleanup.

• Which triplets are supported/not supported? Have you updated the CI baseline?

  all, no

• Does your PR follow the maintainer guide?

  yes

• If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?

  yes

[dg0yt]

• This should be beneficial for cross builds which have a host dependency on qt5-base[core].

... if vcpkg wouldn't install default features for host dependencies: https://github.com/microsoft/vcpkg-tool/pull/177.

[JackBoosY]

cc @Neumann-A

[dg0yt]

It is basically good enough to review, although downstream ports will need changes to fully leverage qt5-base feature control. In any case, this will be the base for the mingw (or more general: cross-build) changes which are another PR.

[Neumann-A]

I think you should add a widgets feature to qt5-base to control the remaining downstream ports. If you want to then control the tools in qt5-tools do that in a separate PR only controlling the tools and nothing more.

So what I would like to see is only changes to qt5-base here.

[dg0yt]

I could revise the focus of the PR to qt5-base (widgets, icu) and add more of the pkgconfig and maintainability changes. Then I would follow with a PR fixing mingw builds at least for qt5-base, qt5-imageformats. And then other PRs could gradually improve the remaining qt5 ecosystem.

[dg0yt]

I think you should add a widgets feature to qt5-base to control the remaining downstream ports.

I just have to avoid an installation order problem. Some port have only transitive dependencies on qt5-base now. In the future, they would need a direct dependency on the gate, qt5-base[core,widgets].

[Neumann-A]

I just have to avoid an installation order problem. Some port have only transitive dependencies on qt5-base now. In the future, they would need a direct dependency on the gate, qt5-base[core,widgets].

So long you make it the default-feature until downstream qt5 ports do it correctly it doesn't matter. Fixing that still can be done later.

[JackBoosY]

Please temporary close this PR if you don't have spare time to finish it.

[dg0yt]

Touching this PR again: It is not enough to control gui or widgets only in qt5-base: This doesn't cut port dependencies of other qt5 modules.

• To avoid transitively requiring these dependencies for the host, qt5-tools really needs the gui feature.
• For users who need Qt Widgets also for Qt Tools, but don't need Qt Quick, the quick feature of qt5-declarative is a necessary and sufficient control. However, this should be a default feature.

[dg0yt]

Requires review, not author-response.

[dg0yt]

If I gate everything only by the qt5-base[gui] feature, it means that for example vcpkg install qt5-svg will be empty and not install Qt5 SVG if only qt5-base[core] is installed. Okay?

[dg0yt]

If I gate everything only by the qt5-base[gui] feature, it means that for example vcpkg install qt5-svg will be empty and not install Qt5 SVG if only qt5-base[core] is installed. Okay?

I would like to keep the feature design as proposed in this PR, with qt5-base[gui], qt5-declarative[quick] and qt5-tools[gui]. Gating only on qt5-base[gui] doesn't allow to cut dependencies from depending ports (e.g. qt5-imageformats). If there are concerns about how the feature selection is passed into each port in absence of direct options, I could still add patches for these options.

[JackBoosY]

I think you should make agreement with @Neumann-A first, sorry for forgot this PR.

[dg0yt]

I think you should make agreement with @Neumann-A first, sorry for forgot this PR.

Waiting for signal from @Neumann-A.

[Neumann-A]

Waiting for signal from @Neumann-A.

I still don't get why you would want to separate qt5-base gui from qt5-tools gui. I mean for qml/quick stuff that makes sense because it drags in the dependency of qt5-declarative but if qt5-base is already build with gui why do you require qt5-tools to be not build wit gui? For me this is just a step into feature hell.

If I gate everything only by the qt5-base[gui] feature, it means that for example vcpkg install qt5-svg will be empty and not install Qt5 SVG if only qt5-base[core] is installed. Okay?

This means qt5-svg is dependent on the gui feature and need to add it as a dependency.

Gating only on qt5-base[gui] doesn't allow to cut dependencies from depending ports (e.g. qt5-imageformats).

What dependencies are you trying to cut? (i don't think it is qt5-imageformats which probably requires the gui feature?)

[JackBoosY]

Any conclusion here?

[dg0yt]

Any conclusion here?

I feel that some requested changes to the current state are not really acceptable or sustainable.

• Controlling features in qt5-tools by presence of features in qt5-base.
• Controlling features in qt5-declarative by properties which correlate but semantically mean a different thing.

I'd appreciate confirmation in one or another direction.

[dg0yt]

I'd appreciate confirmation in one or another direction.

Ping.

[JackBoosY]

I think we might need to confirm these points with @Neumann-A .

[dg0yt]

Any conclusion here?

I feel that some requested changes to the current state are not really acceptable or sustainable.

* Controlling features in `qt5-tools` by presence of features in `qt5-base`.

* Controlling features in `qt5-declarative` by properties which correlate but semantically mean a different thing.

I'd appreciate confirmation in one or another direction.

Ping.

[Adela0814]

I think we might need to confirm these points with @Neumann-A .

@Neumann-A could you please help to review this? Thanks.

[Neumann-A]

Controlling features in qt5-tools by presence of features in qt5-base.

@Adela0814 That is something you guys have to decide if you want ALL the features. I don't see a reason to build qt5-base with gui and qt5-tools without it.

    vcpkg_list(APPEND OPTIONS
        "QT.quick.name="
        "config.qttools.features.assistant.disable=true"
        "config.qttools.features.designer.disable=true"
        "config.qttools.features.distancefieldgenerator.disable=true"
        "config.qttools.features.pixeltool.disable=true"
        "config.qttools.features.qtdiag.disable=true"

Ah maybe I am just annoyed by the name of the feature because it actually doesn't use "QT.gui.name=" (but that is similar to what i said in https://github.com/microsoft/vcpkg/pull/23668#discussion_r856060692; maybe just go with the qtdeclarative approach and spin out the tools with gui as gui-tools instead and the cmd list tools just as single feature). Or just follow https://code.qt.io/cgit/qt/qttools.git/tree/configure.json?h=v5.15.7-lts-lgpl and we don't have to discuss at all. (even if it adds 16 features where probably 3-5 are platform dependent and doesn't need to be features explicitly.)

[dg0yt]

Controlling features in qt5-tools by presence of features in qt5-base.

I take the approval of #29153 as an indication that we don't want that.

• There: control qttools dbus by qtbase dbus presence.
• Here: control qt5-tools gui by qt5-base gui presence.

I admit that gui is a cross-cutting concern, and dbusviewer isn't.

[Neumann-A]

I take the approval of https://github.com/microsoft/vcpkg/pull/29153 as an indication that we don't want that.

@dg0yt

Or just follow https://code.qt.io/cgit/qt/qttools.git/tree/configure.json?h=v5.15.7-lts-lgpl and we don't have to discuss at all. (even if it adds 16 features where probably 3-5 are platform dependent and doesn't need to be features explicitly.)

https://github.com/microsoft/vcpkg/pull/29153 is exactly that. upstream feature == vcpkg feature

[Adela0814]

@dg0yt Please fix the conflicts. Note: I will be converting your PR to draft status. When you respond, please revert to "ready for review". That way, I can be aware that you've responded since you can't modify the tags.

[Adela0814]

Closing this PR since it seems that no progress is being made. Please ping us to reopen if work is still being done.