En fait, c'est déjà un problème purement Windowsien...
Sur un système digne de ce non, Qt est installé au niveau système, il n'a pas a venir avec chaque exécutable.
Dans ce cas il faut justement éviter le linkage statique, en effet; pour la première application qui se lance et qui utilise Qt, les librairies sont chargées en mémoire, les suivantes se lance rapidement car elle ne font que les ré-utiliser...
Dans un système KDE par exemple; l'ensemble des applications graphique est écrit en Qt, même le gestionnaire de fenêtre; et un système sous KDE reste bien bien plus petit que le dossier C:\Windows de la plupart de vos PC.
C'est sur que si Qt est utilisé que pour un tout petit logiciel, c'est overkill, mais si on l'exploite au niveau système, c'est tout de suite plus intéressant.
Après, Windows n'aide pas pour cette façon de concevoir et distribuer les applications... D'ailleurs, c'est le même problème pour Python... Sous Gnu/Linux, un script python sans trop de dépendance s’exécute sur presque toutes les distributions qu'il soit Python2 ou Python3. Sous Windows, c'est un autre problème...
Après reste que sous Linux, packager et distribuer une application reste compliqué, mais bon, la perfection n'existe nul part aujourd'hui.
Pour en revenir a Qt, il faut aussi se dire que ce n'est pas le seul framework graphique C++; c'est pas pour rien que Samsung a basé son OS Tizen sur les EFL; alors qu'il héritait de Meego, qui lui était 100% Qt; il ont fait ce choix pour la très petite embarqué (je ne parle pas des monstres de smartphone d'aujourd'hui qui n'ont rien de vraiment embarqué, mais surtout des montres connecté de la marque), la, EFL, c'est tout aussi jolie, beaucoup beaucoup plus léger (en RAM surtout), par contre, c'est moins sexy/facile a coder que du Qt/QML...
[^] # Re: Qt static
Posté par Fabien PRORIOL . En réponse au journal Réduire la taille des exécutables générés avec PyInstaller. Évalué à 0.
En fait, c'est déjà un problème purement Windowsien...
Sur un système digne de ce non, Qt est installé au niveau système, il n'a pas a venir avec chaque exécutable.
Dans ce cas il faut justement éviter le linkage statique, en effet; pour la première application qui se lance et qui utilise Qt, les librairies sont chargées en mémoire, les suivantes se lance rapidement car elle ne font que les ré-utiliser...
Dans un système KDE par exemple; l'ensemble des applications graphique est écrit en Qt, même le gestionnaire de fenêtre; et un système sous KDE reste bien bien plus petit que le dossier C:\Windows de la plupart de vos PC.
C'est sur que si Qt est utilisé que pour un tout petit logiciel, c'est overkill, mais si on l'exploite au niveau système, c'est tout de suite plus intéressant.
Après, Windows n'aide pas pour cette façon de concevoir et distribuer les applications... D'ailleurs, c'est le même problème pour Python... Sous Gnu/Linux, un script python sans trop de dépendance s’exécute sur presque toutes les distributions qu'il soit Python2 ou Python3. Sous Windows, c'est un autre problème...
Après reste que sous Linux, packager et distribuer une application reste compliqué, mais bon, la perfection n'existe nul part aujourd'hui.
Pour en revenir a Qt, il faut aussi se dire que ce n'est pas le seul framework graphique C++; c'est pas pour rien que Samsung a basé son OS Tizen sur les EFL; alors qu'il héritait de Meego, qui lui était 100% Qt; il ont fait ce choix pour la très petite embarqué (je ne parle pas des monstres de smartphone d'aujourd'hui qui n'ont rien de vraiment embarqué, mais surtout des montres connecté de la marque), la, EFL, c'est tout aussi jolie, beaucoup beaucoup plus léger (en RAM surtout), par contre, c'est moins sexy/facile a coder que du Qt/QML...