Discussion :

[ronchman07]

Bonjour,

Je viens du monde Java et j'aimerais me documenter en vue de créer une application Qt. Je me tourne vers Qt pour son côté multi plateforme, mais également parce que c'est un framework (a priori) bien rodé.
J'ai déjà fait un petit peu de c++, notamment avec Juce sous Visual Studio.

Pour me faire la main, j'ai donc installé Qt creator sur ma machine (Windows), et testé un "Hello world" fenêtré. Tout fonctionne nikel.
Comme mon but n'est pas de contempler mon application uniquement sur ma machine, et buildée avec Qt creator, j'ai cherché un bouton "exporter en .exe", en vain. J'ai ensuite cherché dans la doc, en vain.
J'ai donc cherché sur Google, et je tombe sur une dizaine de threads dans des forums, dont certains datent de 2010, et la plupart n'ont pas de réponse définitive.
Je vois que dans la FAQ ici (http://qt.developpez.com/faq/?page=g...ws-deploiement), il y a à peu près les mêmes instructions que dans les forums ("prendre les .dll de mingw au peu au hasard, dans un dossier qui n'est pas toujours le même, et regarder si ça marche").
D'ailleurs la FAQ ici est écrite pour Qt4, actuellement on est en Qt5.

Ma question est donc la suivante: y a-t-il un moyen simple et industrialisable de créer un .exe distribuable sur n'importe quelle plateforme qui n'a pas Qt, ni Qt creator? Sans vouloir troller, dans Eclipse Java, un click droit sur le projet, et on l'exporte en Jar, en 2 secondes ça fonctionne (vient ensuite le problème de la JVM d'exécution, mais c'est un autre problème).
D'autant que quand je builde mon projet sous Qt creator, il logge bien "launching project from C:/dev/.../myproject.exe", ça veut donc bien dire qu'il arrive à savoir exactement de quelles dll mon projet a besoin, non?
Je trouverais ça incroyable que tant de monde développe sous Qt et se fasse ch... à faire des copier/coller de .dll pour exporter son projet. Comment font les entreprises?

Question subsidiaire: y a-t-il un moyen de faire la même chose simplement pour les Unix? Sortir un .sh ou un .bin? Je sais que pour iOs et Android c'est plus compliqué, mais assez bien expliqué dans la doc.

Merci pour votre lecture de ce long post, et pour vos réponses.

[mintho carmo]

Au boulot, on fait simple : tout est généré automatiquement par un CI jenkins. Parce que toute façon, un "livrable client", ce n'est pas juste un .exe et quelques dll (tout comme ce n'est pas juste un .jar). Du coup, pas besoin de juste un bouton pour cela (Qt Creator est un projet open source, donc tout le monde peut créer un plugin pour déployer une application Qt. Si cela n'existe pas, c'est que tout le monde s'en moque)
Idem pour linux, iOS et Android, de simples scripts et c'est bon

[ronchman07]

Hello,

Merci pour ta réponse.
C'est bien ça que j'avais en tête: si c'est difficile de créer un livrable standalone sur sa machine, alors ça doit être encore moins envisageable de faire de l'intégration continue.
Je suis d'accord pour dire qu'un livrable client ce n'est pas juste un .jar, mais quand tu as le .jar, tu as déjà fait 80% du boulot. En quelques clics c'est fait sous n'importe quel IDE Java.

tout le monde peut créer un plugin pour déployer une application Qt. Si cela n'existe pas, c'est que tout le monde s'en moque

Là je suis un peu moins d'accord: tout le monde ne s'en moque pas, c'est pour ça qu'on trouve des dizaines de threads dans des forums sur ce thème-là. Curieusement je n'ai encore jamais vu de réponse arrêtée. C'est peut-être une question de gros débutant.
Sur une des premières pages du site Qt (http://doc.qt.io/qt-5/topics-app-development.html), il y a marqué: "Qt is designed for developing applications and user interfaces once and deploying them across several desktop and mobile operating systems", mais je n'ai pas trouvé sur le même site comment faire ce "deploying them across several desktop".

Question: Du coup, que fait votre job Jenkins? Il récupère les .dll nécessaires, l'exe du programme, et colle tout ça dans un répertoire? Si Jenkins est installé sur un Unix (95% des cas je pense), où va-t-il chercher les .dll? Et comment faire si on veut builder pour un système Unix?

Merci de vos réponses, j'aimerais y voir clair avant de me lancer dans un gros dev.

[loupium]

Bonjour,

la plupart n'ont pas de réponse définitive.

Etrange, je lis tous les messages depuis presque 2 ans sur le forum Qt et ces questions de débutant sont généralement totalement traité.

prendre les .dll de mingw au peu au hasard,

Il y a aucun hasard !

dans un dossier qui n'est pas toujours le même

Hormis l'emplacement d'installation du SDK (choisit par l'utilisateur) et les numéros de version qui évolue, c'est le même :
Chemin_Installation_SDK/Version_De_La_Lib_Qt/Compilateur_Et_Version_du_compilateur/bin
Quand tu débutes, généralement tu installes le SDK de base avec une seule version de Qt et un seul compilateur. Par exemple chez moi :
C:\Qt\5.4\mingw491_32\bin

D'autant que quand je builde mon projet sous Qt creator, il logge bien "launching project from C:/dev/.../myproject.exe", ça veut donc bien dire qu'il arrive à savoir exactement de quelles dll mon projet a besoin, non?

Car un programme lancé à travers Qt Creator utilise les dll de l'emplacement "C:\Qt\5.4\mingw491_32\bin".

mais quand tu as le .jar, tu as déjà fait 80% du boulot.

Faut quand même pas exagérer. Pour un Hello World à la rigueur.
Non, pour un programme industriel, on crée un installateur, aussi bien pour C++/Qt que pour java, qui encapsule le .exe ou le Jar.
Perso j'utilise InnoSetup. Il existe Qt-Installer-Framework aussi (utilisé pour l'installation du SDK Qt par exemple) mais je l'ai pas testé.
A titre d'exemple, la copie de dll dans mes scripts d'InnoSetup représente 15 à 20 lignes. Et des lignes vraiment pas compliquées puisque c'est du copie-coller, seul le nom de la dll change. Ces lignes représentent 5% du script.
Donc rien qui ne gène une intégration continue.

[mintho carmo]

Je ne sais pas très bien comment fonctionne un fichier .jar, mais déployer une application, c'est aussi gérer les dépendances (autres libs utilisées, autres logiciels), la configuration système (base de registres sous windows, fichier config de linux, etc), la localisation des binaires (dans le même répertoire ou dans system pour windows, user/bin, usr/libs, usr/local, etc sous LInux), la localisation des images, des ressources en général, etc. Et cela change pour MacOSX, Android, iOS...
Donc ce n'est pas une problématique spécifique du C++/Qt, c'est un problème de variété des systèmes.

Jenkins est configuré pour builder, lancer les tests unitaires, l'analyse statique et dynamique, générer la doc développeur et utilisateur, générer les installateur (innoSetup sous windows, .deb/.rpm/depôts sous linux), générer les DVD d'install.
Dans cette histoire, "trouver les dll", c'est accessoire. On configure une fois Jenkins et c'est réglé (cf le lien que j'ai donné pour trouver les dll)

[ronchman07]

Bonjour,

Et merci pour vos réponses.

@loupioum
Quand je dis "la plupart des questions de ce type n'ont pas de réponse définitive sur les forums", je pense que c'est assez clair:

• http://www.qtforum.org/article/34166...t-creator.html => thread de 2010, pas de réponse
• http://www.qtcentre.org/archive/index.php/t-43854.html? => thread de 2011, pas de réponse

De plus, je ne suis pas sûr que ce soit une question de débutant, sinon je pense que vous m'auriez déjà donné une réponse claire. Il y a 64 personnes qui ont vu cette discussion, et vous êtes 2 à me répondre.
Quand je dis "prendre des dll au hasard", bien sûr que j'exagère, mais j'ai pu constater qu'il ne fallait pas toujours prendre les mêmes. Dans les exemples fournis avec Qt creator, il y a des exemples simples qui nécessitent peu de dll (celles de base), et d'autres qui en nécessitent beaucoup plus. Comment je l'ai su? En appuyant sur mon .exe, et en ajoutant la .dll manquante à chaque fois. Il manque 20 dll => j'appuie 20 fois sur mon exe. Pour moi c'est du bricolage (à moins que ça fasse partie de la phase d'initialisation du projet).

J'ai vu que certains posts parlaient de http://www.dependencywalker.com/, ça m'a l'air plutôt bon, mais c'est exlusif à Windows, quid de Linux et autres?

Et si, quand tu as le .jar tu as fait 80% du boulot, le reste c'est le paquet cadeau, le plus important c'est ce qu'il y a à l'intérieur.

Merci pour l'info sur InnoSetup, je vais regarder ça.

Sinon j'ai une dernière question: pour gérer tous ces problèmes de .dll, j'ai vu qu'on pouvait créer un projet linké statiquement, qu'en pensez-vous (mis à part les problèmes de licence)? J'ai l'impression que ça résout tous les problèmes, mais ça a l'air ultra compliqué.

Merci pour vos réponses, je sais bien que C++ est bien plus complexe que Java

[mintho carmo]

sinon je pense que vous m'auriez déjà donné une réponse claire. Il y a 64 personnes qui ont vu cette discussion, et vous êtes 2 à me répondre.

Je t'ai donne un lien qui explique les DLL qu'il faut prendre. Que te faut-il d'autre ? (peut être que les 62 autres personnes n'ont rien de plus a ajouter)
Tu as deux problèmes différents : savoir quels fichiers tu dois fournir aux utilisateurs (cf le tuto) et comment créer un paquetage (cf innoSetup). Aucun de ces 2 problèmes n'est complexe (ie ne nécessite pas d’être un expert. Un débutant peut s'en sortir, mais cela nécessite de lire un peu les tutos et docs)

J'ai vu que certains posts parlaient de http://www.dependencywalker.com/, ça m'a l'air plutôt bon, mais c'est exlusif à Windows, quid de Linux et autres?

Qt utilise des plugins chargés au démarrage de l'application, qui ne peuvent pas être détectés par dependencywalker, donc cela ne fonctionnera pas (cela fonctionnera pour les modules Qt, comme qtcore.dll ou qtgui.dll, mais pas pour qwindows.dll par exemple)

Sinon j'ai une dernière question: pour gérer tous ces problèmes de .dll, j'ai vu qu'on pouvait créer un projet linké statiquement, qu'en pensez-vous (mis à part les problèmes de licence)? J'ai l'impression que ça résout tous les problèmes, mais ça a l'air ultra compliqué

C'est remplacer un problème par un autre problème. Le build de Qt en static est assez complexe, trouver quelques dll l'est beaucoup moins.
En général, on build en static pour diminuer la taille des livrables (mais avec les capacités actuelles des réseaux et des ordis, c'est de moins en moins utile a mon sens)