[Development] Proposing to move deploy tools to qtbase

[Shawn Rutledge]

On 2021 Nov 16, at 12:06, EXT Craig Scott <craig.scott at qt.io<mailto:craig.scott at qt.io>> wrote:

I’m working on adding new CMake APIs for install support for Qt 6.3. As part of that, there will be conveniences for invoking the appropriate xxxdeployqt tool where available. At the moment, macdeployqt and windeployqt live in qttools, whereas androiddeployqt lives in qtbase. I’d like to propose moving macdeployqt and windeployqt to qtbase as well. The motivations for this include:


  *   In order to be able to run deploy-related API tests, we need the deploy tools to be available. It would be unhelpful having the functionality in qtbase but the tests in qttools. It would also complicate CI to have these two things in different repositories.
  *   Other repos will add to the CMake API for install support and will have dependencies on the deploy aspects. qtdeclarative is the obvious one for QML install support. If we don’t move the deploy tools to qtbase, we will have to add a dependency on qttools where it wasn’t needed before in order to test those repos’ install APIs too.
  *   When you only need a fairly minimal Qt build, qtbase might be all you need. It would be nice to still be able to offer the install API for that scenario, but having to add qttools just to be able to use it would block that.
  *   From a maintenance perspective, it hinders development to have the deploy tools split across two different repositories. If you need to add a new option to support a new install feature, for example, or you want to unify aspects of the deploy tools, it is much easier to do that when they are in the one repository.

Both macdeployqt and windeployqt are small and don’t depend on anything other that QtCore (their tests do depend on QtTest as well).

With feature freeze for 6.3 only a few weeks away, it would be good if we could resolve this quickly, if possible.

+1

Maybe they’ll get used more routinely, get more visibility and improvements, as long as we’re sure this is still the right way to go.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20211116/a8d5182d/attachment.html>