Qt pour macOS - Déploiement

Ce document décrit comment créer un bundle macOS et s'assurer que l'application trouve les ressources dont elle a besoin au moment de l'exécution. Nous démontrons les procédures en termes de déploiement de l'application d'exemple Plug & Paint qui est livrée avec le paquet source de Qt.

Les installateurs Qt pour macOS incluent un outil de déploiement qui automatise les procédures décrites ici.

L'offre groupée

Sous macOS, une application GUI doit être construite et exécutée à partir d'un bundle, qui est une structure de répertoire qui apparaît comme une entité unique lorsqu'elle est visualisée dans le Finder. Le bundle d'une application contient généralement l'exécutable et toutes les ressources dont il a besoin. Voici un aperçu de la structure d'un paquet d'applications :

L'offre groupée présente de nombreux avantages pour l'utilisateur :

• Il est facile à installer car il est identifié comme une entité unique.
• Les informations relatives à un bundle sont accessibles à partir du code.

Ceci est spécifique à macOS et dépasse la portée de ce document. Pour plus d'informations sur les bundles, consultez le site Web des développeurs d'Apple.

Pour construire votre application en tant que bundle avec CMake, définissez la propriété MACOSX_BUNDLE sur votre cible exécutable :

set_target_properties(plugandpaint PROPERTIES
    MACOSX_BUNDLE TRUE
)

qmake génère automatiquement un bundle pour votre application. Pour désactiver cette propriété, ajoutez la déclaration suivante au fichier de projet de votre application (.pro) :

CONFIG-=app_bundle

Liaison statique

Si vous voulez garder les choses simples et que vous n'avez que quelques fichiers à déployer, vous pouvez construire votre application avec des bibliothèques à liaison statique.

Construction statique de Qt

Commencez par installer une version statique de la bibliothèque Qt. Rappelez-vous que vous ne pouvez pas utiliser de plugins et que vous devez construire les bibliothèques dépendantes telles que les formats d'image, les pilotes SQL, etc. avec un lien statique.

cd /path/to/Qt
./configure -static <other parameters>

Vous pouvez vérifier les différentes options disponibles en lançant configure -help.

Lier l'application à la version statique de Qt

Une fois que Qt est construit de manière statique, l'étape suivante consiste à régénérer les fichiers de construction et à reconstruire l'application.

Utilisation de CMake

Assurez-vous d'utiliser la commande wrapper qt_add_executable, qui fournit une logique supplémentaire telle que la liaison des plugins Qt dans les constructions statiques de Qt.

Pour construire pour les plateformes Apple, vous devez configurer cmake_minimum_required() à la version 3.21.1 ou à une version plus récente :

cmake_minimum_required(VERSION 3.21.1)

Allez dans le répertoire qui contient l'application :

cd /path/to/Qt/examples/widgets/tools/plugandpaint/app

Ensuite, définissez la variable CMAKE_PREFIX_PATH pour qu'elle pointe vers votre préfixe d'installation. Si vous avez déjà une version de Cmake, supprimez le fichier CMakeCache.txt. Ensuite, relancez CMake :

cmake -DCMAKE_PREFIX_PATH=path/to/Qt/6.11.0/your_platform -S <source-dir> -B <build-dir> -G Ninja

Vous pouvez également utiliser le script de commodité qt-cmake, qui définit la variable CMAKE_PREFIX_PATH pour vous.

path/to/Qt/6.11.0/your_platform/bin/qt-cmake -S <source-dir> -B <build-dir> -G Ninja

Enfin, allez dans votre répertoire de compilation et exécutez votre système de compilation préféré. Dans cet exemple, nous utilisons Ninja.

cd path/to/build/dir
ninja

Maintenant, si tout a été compilé et lié sans erreur, vous devriez avoir un bundle plugandpaint.app prêt à être déployé. Essayez d'installer le bundle sur une machine fonctionnant sous macOS qui n'a pas Qt ou d'applications Qt installées.

Utilisation de qmake

Tout d'abord, allez dans le répertoire qui contient l'application :

cd /path/to/Qt/examples/widgets/tools/plugandpaint/app

Ensuite, lancez qmake pour créer un nouveau fichier makefile pour l'application, et faites un clean build pour créer l'exécutable lié statiquement :

make clean
qmake -config release
make

Vous voudrez probablement établir un lien avec les bibliothèques de version, et vous pouvez le spécifier lorsque vous invoquez qmake. Il se peut que vous souhaitiez profiter du "dead code stripping" pour réduire encore plus la taille de votre binaire. Vous pouvez le faire en passant LIBS+= -dead_strip à qmake en plus du paramètre -config release.

Encore une fois, si tout a été compilé et lié sans erreur, vous devriez avoir un bundle plugandpaint.app prêt à être déployé. Essayez d'installer le bundle sur une machine fonctionnant sous macOS qui n'a pas Qt ou d'applications Qt installées.

Vérification des bibliothèques liées

Vous pouvez vérifier quelles sont les autres bibliothèques liées à votre application à l'aide de la commande otool:

otool -L plugandpaint.app/Contents/MacOs/plugandpaint

Voici à quoi ressemble le résultat pour l'application Plug & Paint liée statiquement :

plugandpaint.app/Contents/MacOS/plugandpaint:
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
        (compatibility version 2.0.0, current version 128.0.0)
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime
        (compatibility version 1.0.0, current version 10.0.0)
/usr/lib/libz.1.dylib
        (compatibility version 1.0.0, current version 1.2.3)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
        (compatibility version 1.0.0, current version 22.0.0)
/usr/lib/libstdc++.6.dylib
        (compatibility version 7.0.0, current version 7.3.0)
/usr/lib/libgcc_s.1.dylib
        (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libmx.A.dylib
        (compatibility version 1.0.0, current version 92.0.0)
/usr/lib/libSystem.B.dylib
        (compatibility version 1.0.0, current version 88.0.0)

Si vous voyez des bibliothèques Qt dans le résultat, cela signifie probablement que des bibliothèques Qt dynamiques et statiques sont installées sur votre machine. L'éditeur de liens choisit toujours la liaison dynamique plutôt que la liaison statique. Si vous souhaitez n'utiliser que des bibliothèques statiques, vous pouvez soit

• déplacer vos bibliothèques dynamiques Qt (.dylibs) dans un autre répertoire pendant que vous liez l'application, puis les déplacer à nouveau,
• soit modifier le fichier Makefile et remplacer les lignes de liaison pour les bibliothèques Qt par le chemin d'accès absolu aux bibliothèques statiques.

Par exemple, remplacez ce qui suit :

-lQtGui

par ceci :

/where/static/qt/lib/is/libQtGui.a

L'exemple Plug & Paint se compose de plusieurs éléments : L'application principale(Plug & Paint), et les plugins Basic Tools et Extra Filters. Comme nous ne pouvons pas déployer de plugins en utilisant l'approche de liaison statique, le paquet que nous avons préparé jusqu'à présent est incomplet. L'application fonctionnera, mais les fonctionnalités seront désactivées en raison des plugins manquants. Pour déployer des applications basées sur des plugins, nous devons utiliser l'approche du framework, qui est spécifique à macOS.

Cadres

Dans cette approche, il faut s'assurer que le runtime Qt est redistribué correctement avec le bundle de l'application, et que les plugins sont installés au bon endroit pour que l'application les trouve.

Il y a deux façons de distribuer Qt avec votre application dans l'approche des cadres :

• Cadre privé à l'intérieur du paquet d'applications.
• Cadre standard (ou utilisation des cadres Qt Installer Framework dans le binaire installé).

La première option est intéressante si vous avez construit Qt d'une manière particulière, ou si vous voulez vous assurer que le framework est présent. Il s'agit simplement de savoir où vous placez les cadres Qt.

La seconde option est intéressante si vous avez de nombreuses applications Qt et que vous souhaitez qu'elles utilisent un seul framework Qt plutôt que plusieurs versions.

Construire Qt en tant que frameworks

Nous supposons que vous avez déjà installé Qt as frameworks, qui est l'option par défaut lors de l'installation de Qt, dans le répertoire /path/to/Qt. Pour plus d'informations sur la façon de construire Qt sans Frameworks, visitez la documentation Qt pour macOS - Problèmes spécifiques.

Lors de l'installation, le nom d'identification des frameworks est défini. Ce nom est utilisé par l'éditeur de liens dynamiques (dyld) pour trouver les bibliothèques pour votre application.

Lier l'application à Qt as Frameworks

Après avoir construit Qt as frameworks, nous pouvons construire l'application Plug & Paint.

Utilisation de CMake

Pour compiler l'application pour les plateformes Apple, vous devez configurer cmake_minimum_required() avec la version 3.21.1 ou une version plus récente :

cmake_minimum_required(VERSION 3.21.1)

Allez dans le répertoire qui contient l'application :

cd /path/to/Qt/examples/widgets/tools/plugandpaint/app

Ensuite, définissez la variable CMAKE_PREFIX_PATH pour qu'elle pointe vers votre préfixe d'installation. Si vous avez déjà une version de Cmake, supprimez le fichier CMakeCache.txt. Ensuite, relancez CMake :

cmake -DCMAKE_PREFIX_PATH=path/to/Qt/6.11.0/your_platform -S <source-dir> -B <build-dir> -G Ninja

Vous pouvez également utiliser le script de commodité qt-cmake, qui définit la variable CMAKE_PREFIX_PATH pour vous.

path/to/Qt/6.11.0/your_platform/bin/qt-cmake -S <source-dir> -B <build-dir> -G Ninja

Enfin, allez dans votre répertoire de compilation et exécutez votre système de compilation préféré. Dans cet exemple, nous utilisons Ninja.

cd path/to/build/dir
ninja

Maintenant, si tout a été compilé et lié sans erreur, vous devriez avoir un bundle plugandpaint.app prêt à être déployé. Essayez d'installer le bundle sur une machine fonctionnant sous macOS qui n'a pas Qt ou d'applications Qt installées.

Utilisation de qmake

Tout d'abord, allez dans le répertoire qui contient l'application :

cd /path/to/Qt/examples/widgets/tools/plugandpaint/app

Exécutez qmake pour créer un nouveau fichier makefile pour l'application, et faites un clean build pour créer l'exécutable lié dynamiquement :

make clean
qmake -config release
make

Ceci construit l'application principale. Utilisez ce qui suit pour construire les plugins :

cd ../plugandpaint/plugins
make clean
qmake -config release
make

Lancez maintenant le otool pour les frameworks Qt, par exemple Qt Gui :

otool -L QtGui.framework/QtGui

Vous obtiendrez le résultat suivant :

QtGui.framework/QtGui:
/path/to/Qt/lib/QtGui.framework/Versions/4.0/QtGui
        (compatibility version 4.0.0, current version 4.0.1)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
        (compatibility version 2.0.0, current version 128.0.0)
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime
        (compatibility version 1.0.0, current version 10.0.0)
/path/to/Qt/QtCore.framework/Versions/4.0/QtCore
        (compatibility version 4.0.0, current version 4.0.1)
/usr/lib/libz.1.dylib
        (compatibility version 1.0.0, current version 1.2.3)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
        (compatibility version 1.0.0, current version 22.0.0)
/usr/lib/libstdc++.6.dylib
        (compatibility version 7.0.0, current version 7.3.0)
/usr/lib/libgcc_s.1.dylib
        (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libmx.A.dylib
        (compatibility version 1.0.0, current version 92.0.0)
/usr/lib/libSystem.B.dylib
        (compatibility version 1.0.0, current version 88.0.0)

Pour les frameworks Qt, la première ligne (c'est-à-dire path/to/Qt/lib/QtGui.framework/Versions/4/QtGui (compatibility version 4.0.0, current version 4.0.1)) devient le nom d'identification du framework qui est utilisé par l'éditeur de liens dynamiques (dyld).

Mais lorsque vous déployez l'application, il se peut que vos utilisateurs n'aient pas installé les frameworks Qt à l'emplacement spécifié. C'est pourquoi vous devez soit fournir les frameworks à un emplacement convenu, soit les stocker dans le bundle. Quelle que soit la solution choisie, vous devez vous assurer que les frameworks renvoient le nom d'identification approprié pour eux-mêmes, et que l'application recherche ces noms. Heureusement, nous pouvons contrôler cela grâce à l'outil de ligne de commande install_name_tool.

L'outil install_name_tool fonctionne en deux modes, -id et -change. Le mode -id est destiné aux bibliothèques et aux frameworks et nous permet de spécifier un nouveau nom d'identification. Nous utilisons le mode -change pour modifier les chemins dans l'application.

Testons-le en copiant les frameworks Qt dans le bundle Plug & Paint. En regardant la sortie de otool pour le bundle, nous pouvons voir que nous devons copier les frameworks QtCore et QtGui dans le bundle. Nous supposerons que nous sommes dans le répertoire où nous avons construit l'ensemble.

mkdir plugandpaint.app/Contents/Frameworks
cp -R /path/to/Qt/lib/QtCore.framework
        plugandpaint.app/Contents/Frameworks
cp -R /path/to/Qt/lib/QtGui.framework
       plugandpaint.app/Contents/Frameworks

Tout d'abord, nous créons un répertoire Frameworks à l'intérieur de l'offre groupée. Ceci est conforme à la convention d'application de macOS. Nous copions ensuite les frameworks dans le nouveau répertoire. Comme les frameworks contiennent des liens symboliques, nous utilisons l'option -R.

install_name_tool -id @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore
       plugandpaint.app/Contents/Frameworks/QtCore.framework/Versions/4.0/QtCore
install_name_tool -id @executable_path/../Frameworks/QtGui.framework/Versions/4.0/QtGui
       plugandpaint.app/Contents/Frameworks/QtGui.framework/Versions/4.0/QtGui

Nous lançons ensuite install_name_tool pour définir les noms d'identification des frameworks. Le premier argument après -id est le nouveau nom, et le deuxième argument est le framework que nous voulons renommer. Le texte @executable_path est une variable spéciale de dyld qui indique à dyld de commencer à chercher où se trouve l'exécutable. Les nouveaux noms précisent que ces cadres se trouvent dans le répertoire situé directement sous le répertoire Frameworks.

install_name_tool -change path/to/Qt/lib/QtCore.framework/Versions/4.0/QtCore
        @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore
        plugandpaint.app/Contents/MacOs/plugandpaint
install_name_tool -change path/to/qt/lib/QtGui.framework/Versions/4.0/QtGui
        @executable_path/../Frameworks/QtGui.framework/Versions/4.0/QtGui
        plugandpaint.app/Contents/MacOs/plugandpaint

Maintenant, l'éditeur de liens dynamiques sait où chercher QtCore et QtGui. Nous devons nous assurer que l'application sait également où trouver la bibliothèque, en utilisant le mode install_name_tool's -change. Il s'agit essentiellement de remplacer des chaînes de caractères, afin de faire correspondre les noms d'identification que nous avons définis plus tôt aux frameworks.

Enfin, le framework QtGui dépend de QtCore, nous devons donc nous rappeler de changer la référence pour QtGui:

install_name_tool -change path/to/Qt/lib/QtCore.framework/Versions/4.0/QtCore
        @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore
        plugandpaint.app/Contents/Frameworks/QtGui.framework/Versions/4.0/QtGui

Après cela, nous lançons à nouveau otool et constatons que l'application peut trouver les bibliothèques.

Les plugins de l'exemple Plug & Paint le rendent intéressant. Les étapes de base que nous devons suivre avec les plugins sont les suivantes :

• placer les plugins dans le bundle,
• exécuter le site install_name_tool pour vérifier si les plugins utilisent la bonne bibliothèque,
• et s'assurer que l'application sait où chercher les plugins.

Nous pouvons placer les plugins où nous voulons dans le bundle, mais le meilleur emplacement est de les placer sous Contents/Plugins. Lorsque nous avons créé les plugins Plug & Paint, sur la base de la variable DESTDIR dans leur fichier .pro, les fichiers .dylib des plugins se trouvent dans le sous-répertoire plugins sous le répertoire plugandpaint. Il suffit de déplacer ce répertoire au bon endroit.

mv plugins plugandpaint.app/Contents

Par exemple, si nous lançons otool sur le fichier .dylib du plugin Basic Tools, nous obtenons les informations suivantes.

libpnp_basictools.dylib:
libpnp_basictools.dylib
       (compatibility version 0.0.0, current version 0.0.0)
/path/to/Qt/lib/QtGui.framework/Versions/4.0/QtGui
       (compatibility version 4.0.0, current version 4.0.1)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
       (compatibility version 2.0.0, current version 128.0.0)
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime
       (compatibility version 1.0.0, current version 10.0.0)
/path/to/Qt/lib/QtCore.framework/Versions/4.0/QtCore
       (compatibility version 4.0.0, current version 4.0.1)
/usr/lib/libz.1.dylib
       (compatibility version 1.0.0, current version 1.2.3)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
       (compatibility version 1.0.0, current version 22.0.0)
/usr/lib/libstdc++.6.dylib
       (compatibility version 7.0.0, current version 7.3.0)
/usr/lib/libgcc_s.1.dylib
       (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libmx.A.dylib
       (compatibility version 1.0.0, current version 92.0.0)
/usr/lib/libSystem.B.dylib
       (compatibility version 1.0.0, current version 88.0.0)

Nous pouvons alors voir que le plugin est lié aux frameworks Qt sur lesquels il a été construit. Comme nous voulons que les plugins utilisent le framework dans le bundle de l'application, nous les modifions de la même manière que nous l'avons fait pour l'application. Par exemple, pour le plugin Basic Tools :

install_name_tool -change /path/to/Qt/lib/QtCore.framework/Versions/4.0/QtCore
        @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore
        plugandpaint.app/Contents/plugins/libpnp_basictools.dylib
install_name_tool -change /path/to/Qt/lib/QtGui.framework/Versions/4.0/QtGui
        @executable_path/../Frameworks/QtGui.framework/Versions/4.0/QtGui
        plugandpaint.app/Contents/plugins/libpnp_basictools.dylib

Nous devons également modifier le code de tools/plugandpaint/mainwindow.cpp à cdUp() pour nous assurer que l'application trouve les plugins. Ajoutez le code suivant au fichier mainwindow.cpp:

#elif defined(Q_OS_MAC)
if (pluginsDir.dirName() == "MacOS") {
    pluginsDir.cdUp();
}
#endif

Le code supplémentaire dans tools/plugandpaint/mainwindow.cpp nous permet également de visualiser les plugins dans le Finder, comme le montre l'image. Nous pouvons également ajouter des plugins étendant Qt SQL, par exemple en ajoutant des pilotes SQL ou des formats d'image. Il suffit de suivre la structure de répertoire décrite dans la documentation des plugins et de s'assurer qu'ils sont inclus dans le site QCoreApplication::libraryPaths(). Faisons-le rapidement avec les formats d'image, en suivant la procédure décrite plus haut. Copiez les plugins de format d'image de Qt Image Formats dans le bundle : cp -R /path/to/Qt/plugins/imageformats pluginandpaint.app/Contents/plugins Utilisez install_name_tool pour lier les plugins aux frameworks du bundle : install_name_tool -change /path/to/Qt/lib/QtGui.framework/Versions/4.0/QtGui @executable_path/../Frameworks/QtGui.framework/Versions/4.0/QtGui plugandpaint.app/Contents/plugins/imageformats/libqjpeg.dylib install_name_tool -change /path/to/Qt/lib/QtCore.framework/Versions/4.0/QtCore @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore plugandpaint.app/Contents/plugins/imageformats/libqjpeg.dylib Mettre à jour le code source de tools/plugandpaint/main.cpp pour prendre en compte les nouveaux plugins. Après avoir construit le site QApplication, nous ajoutons le code suivant : QDir dir(QCoreApplication::applicationDirPath()); dir.cdUp(); dir.cd("plugins"); QCoreApplication::setLibraryPaths(QStringList(dir.absolutePath())); Tout d'abord, nous demandons à l'application de ne rechercher que les plugins de ce répertoire. Dans notre cas, nous voulons que l'application ne recherche que les plugins que nous distribuons avec le bundle. Si nous faisions partie d'une plus grande installation de Qt XML, nous aurions pu utiliser QCoreApplication::addLibraryPath() à la place.

Vous devriez maintenant être en mesure de déplacer l'application sur une autre machine macOS et de l'exécuter sans que Qt soit installé. Alternativement, vous pouvez déplacer vos frameworks qui vivent en dehors du bundle dans un autre répertoire et voir si l'application fonctionne toujours.

Si vous stockez les frameworks dans un autre emplacement en dehors du bundle, la technique de liaison de votre application est similaire ; vous devez vous assurer que l'application et les frameworks se mettent d'accord sur l'endroit où rechercher les bibliothèques Qt ainsi que les plugins.

Création du paquetage de l'application

Lorsque vous avez fini de lier votre application à Qt, soit de manière statique, soit en tant que frameworks, l'application est prête à être distribuée. Pour plus d'informations, consultez le site web Apple Developer.

Bien que le processus de déploiement d'une application comporte quelques pièges, une fois que vous connaissez les différents problèmes, vous pouvez facilement créer des paquets que tous les utilisateurs de macOS apprécieront.

Dépendances de l'application

Plugins Qt

Toutes les applications Qt GUI nécessitent un plugin qui met en œuvre la couche Qt Platform Abstraction (QPA) dans Qt. Pour macOS, le nom du plugin de plateforme est libqcocoa.dylib. Ce fichier doit être situé dans un sous-répertoire spécifique (par défaut, platforms) de votre répertoire de distribution. Il est également possible d'ajuster le chemin de recherche utilisé par Qt pour trouver ses plugins, comme décrit ci-dessous.

Votre application peut également dépendre d'un ou de plusieurs plugins Qt, tels que le plugin du format d'image JPEG ou le plugin d'un pilote SQL. Veillez à distribuer tous les plugins Qt dont vous avez besoin avec votre application. Comme pour le plugin de plate-forme, chaque type de plugin doit être situé dans un sous-répertoire spécifique (tel que imageformats ou sqldrivers) de votre répertoire de distribution.

Le chemin de recherche des plugins Qt (ainsi que quelques autres chemins) est codé en dur dans la bibliothèque QtCore. Par défaut, le premier chemin de recherche des plugins est codé en dur sous la forme /path/to/Qt/plugins. L'utilisation de chemins prédéterminés présente toutefois certains inconvénients. Par exemple, ils peuvent ne pas exister sur la machine cible. Vous devez donc vérifier plusieurs alternatives pour vous assurer que les plugins Qt sont trouvés :

• Utilisation de qt.conf. C'est l'approche recommandée car elle offre le plus de flexibilité.
• En utilisant QApplication::addLibraryPath() ou QApplication::setLibraryPaths().
• En utilisant un utilitaire d'installation tiers pour modifier les chemins d'accès codés en dur dans la bibliothèque QtCore.

Le document Comment créer des plugins Qt décrit les points auxquels vous devez prêter attention lors de la création et du déploiement de plugins pour les applications Qt.

Bibliothèques supplémentaires

Vous pouvez vérifier les bibliothèques avec lesquelles votre application est liée en utilisant otool. Exécutez cette commande avec le chemin d'accès à l'application comme argument :

otool -L MyApp.app/Contents/MacOS/MyApp

Les bibliothèques spécifiques au compilateur doivent rarement être redistribuées avec votre application. Mais il y a plusieurs façons de déployer des applications, car Qt peut être configuré, construit et installé de plusieurs façons sur macOS. Typiquement, vos objectifs vous aident à déterminer comment vous allez déployer l'application. Les dernières sections décrivent quelques éléments dont vous devez tenir compte lors du déploiement de votre application.

L'outil de déploiement macOS

L'outil de déploiement macOS se trouve à l'adresse suivante : QTDIR/bin/macdeployqt. Il est conçu pour automatiser le processus de création d'un bundle d'application déployable qui contient des bibliothèques Qt en tant que cadres privés.

L'outil de déploiement macOS déploie également les plugins Qt, selon les règles suivantes (sauf si l'option -no-plugins est utilisée) :

• Le plugin de plateforme est toujours déployé.
• Les versions de débogage des plugins ne sont pas déployées.
• Les plugins de conception ne sont pas déployés.
• Les plugins de format d'image sont toujours déployés, à l'exception du plugin de format d'image SVG qui n'est déployé que si l'application utilise le module Qt SVG module.
• Les plugins du moteur d'icônes sont toujours déployés.
• Le plugin de support d'impression est toujours déployé.
• Les plugins de pilote SQL sont déployés si l'application utilise le module Qt SQL module.
• Le plugin d'accessibilité est toujours déployé.
• Le plugin de style est toujours déployé.

Pour inclure une bibliothèque tierce dans le paquet d'applications, copiez-la manuellement dans le paquet, après sa création.

macdeployqt prend en charge les options suivantes :

Nom du volume

Le nom de volume d'une image disque (le texte affiché dans le titre de la fenêtre d'un fichier .dmg ouvert) créée avec -dmg est basé sur le chemin d'accès à l'application lorsque macdeployqt est exécuté. Par exemple, la commande suivante crée une image disque pour une application Qt Quick:

macdeployqt /Users/foo/myapp-build/MyApp.app -qmldir=/Users/foo/myapp/qml -dmg

Le nom du volume résultant sera :

/Users/foo/myapp-build/MyApp.app

Pour s'assurer que le nom de volume ne contient que le nom de l'application et non le chemin d'accès à la machine de déploiement, exécutez macdeployqt dans le même répertoire :

cd /Users/foo/myapp-build
macdeployqt MyApp.app -qmldir=/Users/foo/myapp/qml -dmg

Le nom de volume résultant sera alors :

MyApp.app

Droits

Lors de la signature, macdeployqt utilisera automatiquement le premier fichier .entitlements qu'il trouve dans le sous-répertoire Contents/Resources/ du paquet d'applications, s'il est présent. Pour éviter les erreurs, assurez-vous qu'il y a au maximum un fichier .entitlements dans ce dossier.