Je suis bloqué au moment de la diffusion d'un projet vers windows et linux. J'ai compilé en mode release. Le tuto de Mathieu Nebra précise qu'il faut joindre à l'executable les .dll, je ne sais absolument pas où les trouver. J'ai aussi lu que sous linux, il fallait chercher des .so.
Voilà où j'en suis, je suis étonné de ne pas avoir trouvé grand chose sur le sujet.
>Mais pourquoi parlait il alors de joindre les dll ?
Je n'ai pas lu ce cours, mais je suppute qu'il avait en tête une méthode bien cracra qui porte le terme pompeux d'installation à la XCOPY.
En fait faire un gros copier-coller bien sale d'un répertoire à un autre. (C'est le genre de truc qui marchouillait à l'époque de MSDOS, il y a plus de 25 ans).
Normalement, la documentation de Qt indique l'arborescence des fichiers qui doivent être copiés lors de l'installation. Votre fichier MSI sera un simple conteneur de tous les fichiers et de l'endroit où les copier par rapport au répertoire d'installation choisi par l'utilisateur.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
La solution que tu me propose permet bien de changer d'ordi tout en restant sur le meme OS ?
Si je compile sous W7, cela fonctionnera t'il avec toutes les versions (j'ai une Vbox avec W7) ?
Ce qui m'étonne aussi c'est que sous W, on utilise tjr des exécutables ; c'est pas possible de déployer simplement mon projet comme un exécutable ? comment font les éditeurs de logiciels ?
>La solution que tu me propose permet bien de changer d'ordi tout en restant sur le meme OS ?
Nope, vous pouvez changer d'ordinateur ET d'OS.
Un MSI fonctionne sur autant de plateforme Windows que nécessaire.
Si vous configurez correctement un MSI, il peut installer des programmes, dll, ocx, ... différents en fonction de l'OS sur lequel on le lance.
Si votre programme est portable sur tous les Windows cible, pas besoin d'utiliser cette fonctionnalité. (Mais il fonctionne sous Win95 votre bidule ?, Le MSI pourra prévenir de la version minimale de Windows sans que vous n'ayez la moindre chose à coder).
>Si je compile sous W7, cela fonctionnera t'il avec toutes les versions
La version Windows sous laquelle vous compilez n'a aucune importance. Ce qui compte c'est la version cible de votre projet.
Si la version cible de votre projet, c'est Win95, ça fonctionnera sur Win95 et supérieur.
>on utilise tjr des exécutables
Et pourquoi pas ? C'est rétro-compatible avec les programmes 32bits (je crois que c'est plus le cas pour les 16 bits sans bidouilles).
>c'est pas possible de déployer simplement mon projet comme un exécutable ?
Oui, mais c'est beaucoup plus chiant et beaucoup beaucoup moins fiable.
Aucun intérêt à faire un installateur exécutable par rapport à un MSI (à part entrainer l'anti-virus à nous casser les noix).
>comment font les éditeurs de logiciels ?
Un MSI, ou un exécutable qui contient un MSI, ou un exécutable qui télécharge un MSI, ou ils vous font payer un consultant pour faire l’installation à la main (sic! et c'est pas donné), etc...
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Les langages de programmation tels que C/C++ ont la particularité suivante : une fois compilé, le code généré, celui qui sera effectivement interprété par ton ordinateur, utilise un système d'écriture que seul le processeur dudit ordinateur peut comprendre. Qui a dit langage machine ? Ainsi, une machine M1 dotée d'un processeur de type P sera capable d'exécuter un exécutable généré depuis une machine M2 possédant un processeur "similaire" à P. Mais compte tenu de la standardisation dans l'encodage des données destinées au processeur, il est de nos jours assez courant qu'un exécutable généré sur une machine [NomOS, xy bits] puisse être exécuté sur une machine portant la même architecture, même si les processeurs ne sont pas tout à fait identiques. Mais cela n'est que théorique car en général on utilise des librairies tierces dans nos applications et celles-ci ne présentent pas toujours le même support d'une plateforme à une autre. Qt est plutôt robuste de ce côté là et sauf cas de bugs, les cas marginaux sont en général indiqués dans la doc.
Pour ce qui est de Qt, tu n'a pas besoin de créer un installateur pour ton programme. En effet afin d'assurer une désinstallation "clean", un installeur sauvegarde en général diverses informations sur l'ordinateur l'ayant exécuté. Mais si ton programme ne requiert pas 3600 dépendances variant d'une plateforme à une autre, tu peux tout simplement copier ton exécutable dans un certain dossier. Maintenant en essayant de l'exécuter, un message d'erreur indiquant qu'une certaine DLL n'a pas pu être trouvée apparaîtra. Le nombre de DLL à copier dans le dossier de l'exécutable varie en fonction du service fourni par l'application. En général voici le minimum requis :
Tu trouveras ces DLL quelque part dans le répertoire où t'as installé Qt : (par exemple C:\Qt\5.9\mingw53_32\bin). Enfin sous Windows, il faut en plus créer un répertoire platforms dans le dossier contenant l'exécutable puis y copier la DLL qwindows.dll. Celle-ci peut aussi être retrouvée à partir du répertoire où tu as installé Qt (par exemple C:\Qt\5.9\mingw53_32\plugins\platforms). Zippes le tout puis files-le à quelqu'un possédant le même OS que le tien : l'application devrait démarrer.
Pour Linux, je te conseil de fournir un makefile* avec deux cibles : all (la cible par défaut) et install (pour laquelle on pourra spécifier une "variable"** PREFIX qui permet de spécifier où installer le projet). Cela te simplifiera la vie : tu n'auras pas fournir de paquets pour tout les gestionnaires de paquets. Les gestionnaires de paquets Linux permettent souvent (en tout cas pour pacman et apt) de créer facilement le paquet à partir du makefile. La personne voulant créer son paquet pourra le faire simplement.
La cible all compilera le projet en entier.
La cible install copiera les fichiers où il y a besoin de les copier, en prenant en compte PREFIX. Si par exemple tu dois copier un fichier dans /bin et que l'utilisateur mets PREFIX à ~, l'installation se fera dans ~/bin.
Pour les dépendances (Qt, ...), je te conseillerai de laisser les gestionnaires de paquets s'en charger (i.e. faire comme si elles étaient présente sur le système) et lister dans un README (ou mieux, avoir un script, si c'est faisable, qui vérifie la présence des dépendances). Si quelqu'un veux créer le paquet pour sa distribution, il pourra utiliser la gestion des dépendances de son gestionnaire de paquet.
En espérant t'avoir aidé.
* Si bien sûr tu n'es pas contre distribuer les sources.
** Il n'y a pas vraiment de variables dans un makefile, juste des macros.
@misterFad, le déploiement à la XCOPY, c'était "valable" il y a 30 ans quand on était sous DOS, où il n'y avait pas d'anti-virus, que le poste était mono-user et que l'OS était assez con pour monté en mémoire commune n'importe quelle cochonnerie qui trainait sur une disquette.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Je ne faisais pas tant allusion à XCOPY ; juste un Ctrl+C -> Ctrl+V au sein d'une même ou entre plusieurs arborescences de fichier. Après tout, même un installateur aura besoin à un moment de copier l'exécutable ainsi que les dépendances vers la machine cible. Dans le cas d'un déploiement conséquent, utiliser un installateur est effectivement pertinent, voire nécessaire.
Au passage je n'ai plus d'exemples qui me viennent à l'esprit mais il m'est déjà arrivé, pour certaines applications, de juste télécharger un fichier .zip plutôt qu'un installateur qui peut-être ira jusqu'à écrire dans les registres de mon PC. Mais de mémoire, il semble que ce genre de release est souvent mis en place afin de permettre l'exécution d'un programme depuis un compte utilisateur ne possédant pas les droits d'administrateur. En toute circonstances, aucun des deux modes de déploiement n'est virus-safe : c'est le boulot de l'utilisateur de faire attention à ce qu'il télécharge.
>Je ne faisais pas tant allusion à XCOPY ; juste un Ctrl+C -> Ctrl+V
Votre "Ctrl+C -> Ctrl+V", c'est ce que fait XCOPY, en encore moins fiable (gestion des droits lecture/écriture, copie de ces même droits, gestion des fichiers en cours d'exécution, etc, tout ça encore plus au fraise qu'avec XCOPY).
>Après tout, même un installateur aura besoin à un moment de copier l'exécutable
L'exécutable est dans le MSI, impossible d'avoir des verrous à la con sur les fichiers type "index Windows".
L'installation se fait par le service d'installation qui tourne en Administrateur Local, donc pas de problème de droits sur le système de fichier à la con.
Le comptage de référence des Dll, les scripts d’enregistrement-désenregistrement dans la base de registre, etc..., tu comptes faire ça quand entre le Ctrl+C et le Ctrl+V ? (ainsi que l'installation des certificats pour l'éditeur, etc...)
>ainsi que les dépendances vers la machine cible.
C'est qui qui fera le bidouillage de Dll différentes en fonction de l'OS de la machine hôte ? MSI il fait ça juste avec une variable d'installation "auto-initialisable".
etc...
En résumé "Ctrl+C -> Ctrl+V", c'est tout pourri et l'installateur MSI c'est bien mieux, et ça coût rien à faire.
>Dans le cas d'un déploiement conséquent, utiliser un installateur est effectivement pertinent, voire nécessaire.
C'est quoi t'as limite ? Sachant qu'avec MSVC t'es toujours obligé de données les redistribuables C-Runtime de VC et que Qt demande toujours une palanqué de Dll ?
Moi, la limite, c'est dés que tu crées un projet, basta.
> de juste télécharger un fichier .zip plutôt qu'un installateur
Oui, ça arrive pour les éditeurs fainéant ou des outils pour développeur avec les sources où c'est à l'utilisateur de faire tout le boulot avec un README de 15 pages pour une application console toutes moisie.(Quand l'éditeur n'est assez fainéant pour pas juste te dire : "lit le code et démerde toi".
>qui peut-être ira jusqu'à écrire dans les registres de mon PC
Tu dois confondre avec des exe auto-extractible, qui copie le MSI interne puis exécute se MSI. (Ou, à l'époque du DOS, essayait de faire la même chose que le service d'installation mais en beaucoup plus merdique).
>depuis un compte utilisateur ne possédant pas les droits d'administrateur.
C'est quoi cette astuce qui ne fonctionne que sur des réseaux dont les administrateurs sont des Mickey ???
> aucun des deux modes de déploiement n'est virus-safe
L'un demande des droits administrateurs de malade, pas l'autre, il n'y a pas photo.
L'un est facilement manageable par les administrateurs, pas l'autre, il n'y a pas photo.
>c'est le boulot de l'utilisateur de faire attention à ce qu'il télécharge.
C'est plutôt à l’administrateur de mettre en place une sécurité correcte, y compris en briefant correctement ses utilisateurs.
Et surtout, ne prenez pas comme exemple les installations à la Oracle, c'est du foutage de gueule avec les exécutables JAVA et les variables d'environnement à la con.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
>Je ne faisais pas tant allusion à XCOPY ; juste un Ctrl+C -> Ctrl+V
Votre "Ctrl+C -> Ctrl+V", c'est ce que fait XCOPY, en encore moins fiable (gestion des droits lecture/écriture, copie de ces même droits, gestion des fichiers en cours d'exécution, etc, tout ça encore plus au fraise qu'avec XCOPY).
Un exécutable, c'est avant tout un fichier. Il n'y a donc absolument aucun problème à le copier dans un répertoire puis à en zipper le contenu. Que ce soit fait par XCOPY ou depuis l'interface graphique, l'essentiel est que le fichier soit copié. C'est peut-être mieux sous Windows d'utiliser un MSI mais la solution que je proposais plus haut n'a aucunement la prétention d'être la meilleure. Elle était juste sensée guider l'initiateur de ce fil de discussion (s'agissant du déploiement d'une application Qt).
bacelar a écrit:
>Après tout, même un installateur aura besoin à un moment de copier l'exécutable
L'exécutable est dans le MSI, impossible d'avoir des verrous à la con sur les fichiers type "index Windows".
L'installation se fait par le service d'installation qui tourne en Administrateur Local, donc pas de problème de droits sur le système de fichier à la con.
Le comptage de référence des Dll, les scripts d’enregistrement-désenregistrement dans la base de registre, etc..., tu comptes faire ça quand entre le Ctrl+C et le Ctrl+V ? (ainsi que l'installation des certificats pour l'éditeur, etc...)
>ainsi que les dépendances vers la machine cible.
C'est qui qui fera le bidouillage de Dll différentes en fonction de l'OS de la machine hôte ? MSI il fait ça juste avec une variable d'installation "auto-initialisable".
etc...
En résumé "Ctrl+C -> Ctrl+V", c'est tout pourri et l'installateur MSI c'est bien mieux, et ça coût rien à faire.
>Dans le cas d'un déploiement conséquent, utiliser un installateur est effectivement pertinent, voire nécessaire.
C'est quoi t'as limite ? Sachant qu'avec MSVC t'es toujours obligé de données les redistribuables C-Runtime de VC et que Qt demande toujours une palanqué de Dll ?
Moi, la limite, c'est dés que tu crées un projet, basta.
Par "déploiement conséquent" j'entends tout simplement un déploiement pour lequel une automatisation des tâches est effectivement nécessaire. Libre à Pulsar98 de procéder à son propre jugement sur la question. Et quand je parlais d'installateur je pensais par exemple à Inno Setup. De plus durant mon stage par exemple, je n'étais même pas autorisé à installer Notepad++ tout simplement parce que je ne disposais pas des droits d'aministrateur. J'ignore ce que ça donne avec les MSI mais personnellement je n'en créerais un que si c'est vraiment nécessaire. En plus les MSI sont propres à Windows. J'aime bien quand c'est multiplate-forme.
Au passage même le setup de Miscrosoft Visual Studio (produit par Microsoft) n'est pas fichu de procéder à une désinstallation correcte de l'IDE, c'est dire. Pour résumer, mettre en place un setup c'est bien. Mais s'en priver lorsque cela n'est pas nécessaire n'est absolument pas grave (de mon point de vue).
C'est simple mais faire un MSI, c'est aussi simple et on n'a beaucoup moins d'emmerdes.
>Un exécutable, c'est avant tout un fichier.
"Dans" un fichier, il y a aussi les ACE des ACL, des propriétés (canaux dynamiques), etc...
Et ils passent comment dans un zip ou un Ctrl C + Ctrl V ?
Contrairement à ce que veut faire croire la conception des années 1970 d'UNIX, un fichier, c'est pas une suite d'octet, très loin de là.
>je n'étais même pas autorisé à installer Notepad++ tout simplement parce que je ne disposais pas des droits d'aministrateur
Rien à voir avec les "droits d'aministrateur" (qui ne veut rien dire de concret sous Windows depuis Windows Vista), il est tout à fait possible de laisser l'installation de MSI ( de préférence signés ) possible aux utilisateurs lambda. Que les administrateurs vous aient blousé avec cette excuse, c'est le jeu du chat et de la souris entre dev et admin, c'est le jeu ma petite Lucette.
> je n'en créerais un que si c'est vraiment nécessaire
Comme c'est encore plus simple que de faire un zip, le "nécessaire", ça sent le dogmatisme.
>En plus les MSI sont propres à Windows. J'aime bien quand c'est multiplate-forme.
Et d'après vous, pourquoi les gestionnaires de package existe sous Linux ?
Vous faites des zip pour les plateformes Linux ?
Non, alors arrêtez de faire le faux flemmard pour M$ et pas pour le pingouin.
ZIP, c'est pas très portable non plus alors.
>Miscrosoft Visual Studio (produit par Microsoft) n'est pas fichu de procéder à une désinstallation correcte de l'IDE, c'est dire
Imagines sans.
C'est pas un marteau magique, gars.
Des packages RPM ou DEB problématiques, ça doit aussi exister.
Faut pas jeter le bébé avec l'eau du bain.
>Mais s'en priver lorsque cela n'est pas nécessaire n'est absolument pas grave (de mon point de vue).
Mais quand les outils intégrés à Qt le font facilement, c'est vraiment du masochisme que de faire des conneries à base de XCOPY.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Oui. Et Mac aussi. Android, la question ne se pose pas, puisque Qt cree directement un apk. Et iOS, pareil je crois.
bacelar a écrit:
C'est simple mais faire un MSI, c'est aussi simple et on n'a beaucoup moins d'emmerdes.
Quand on utilise l'outil qtdeploy, cela copie directement les dll ou dynlib dans le répertoire de compilation du projet. Il ne reste plus qu'a zip le répertoire pour le partager.
Quand on a une simple application standalone (ce qui est souvent le cas pour ici), c'est suffisant.
>Quand on a une simple application standalone (ce qui est souvent le cas pour ici), c'est suffisant.
J'ai du mal à voir comment un zip peut gérer CORRECTEMENT les droits d'accès, avec les exécutable non modifiables, les fichiers de configurations dans les répertoires de l'utilisateur, les Dll dans des répertoires avec les droits adéquates etc...
Donc, une installation d'une application qui ne demande aucun droit particuliers dans un répertoire avec toutes les sécurités à l'ouest par un utilisateur root, pourquoi pas, mais ça fait quand même installation de cochon ou rien.
Si les apk existent et que Qt les crée, il y a une raison.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Il ne gerer rien du tout. Tu dezipes et tu lances l'application directement dans le répertoire. Pas de copie de dll, pas d'accès aux exécutables ou fichiers de configuration. C'est justement le principe des applications "noinstall"
Et Qt n'a pas créé les apk, c'est le format de paquet obligatoire sur Android. C'est une contrainte technique d'Android, il n'est pas possible de faire des applications "noinstall" sur mobile en general.
>C'est justement le principe des applications "noinstall"
Houais, sauf que sur une machine configurée correctement, on doit se coller le "chmod 777" bien cracra avant d’exécuter le bidule, etc...
>c'est le format de paquet obligatoire sur Android.
Ce que devrait faire tout OS, et ce que fait Windows pour toutes les applications du Store Microsoft. etc...
> C'est une contrainte technique d'Android,
C'est pas une contrainte, c'est une feature.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Diffusion d'un projet
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.