Ceci est mon retour d'utilisateur de qmake en tant que développeur de logiciel propriétaire pour le milieu de la micro-électronique (ne me jetez pas la pierre, il faut bien payer son loyer...).
qmake marche bien pour gérer des projets C++/Qt «classique». Mais dès que tu veux faire des trucs «un peu exotique», c'est une vraie plaie dans le c**. Il faut se montrer très «créatif» dans les .pro et utiliser des fonctionnalités non documentées dont tu découvres l’existence dans le wiki de Qt ou sur des forums.
Un exemple concret. Notre logiciel utilise un framework tierce (FlexNet) pour gérer les licences et s'assurer que le client utilise notre outil dans les conditions prévus par le contrat qu'il a signé (notamment nombre d'instances du logiciel pouvant s'exécuter en parallèles et fonctionnalités du logiciel. Ce framework nous est fourni sous la forme d'une archive à décompresser, et exécuter un simple make dedans pour générer la bibliothèque à intégrer dans notre outil. Vu que nos clients utilisent diverses architectures et plateformes (essentiellement RHEL 5/6/7 en amd64, mais pas que), nous avons décidés (à tort ?) d'intégrer ce framework dans notre projet .pro sous forme de sous-projet source pourqu'il soit compilé automatiquement par notre système d'intégration continue pour les plateformes cibles. Et là, c'est le drame parce qu'il n'y a pas de moyen simple d'expliquer à qmake que ce sous-projet se compile avec un simple make et qu'il peut utiliser le résultat pour le linker à notre soft. Et on ne peut pas non plus créer un .pro spécifique à ce projet (du moins facilement, j'ai essayé plus d'une fois), parce que le make sus-nommé fait de la «magie» : il génère un exécutable qui va générer les .h/.so que l'on va utiliser (l'éditeur du framework a choisi la sécurité par l'obscurité. L’exécutable va générer une version obfusqué de toute leur tambouille interne, qui va être appelé par l'API à laquelle on a accès). Du coup, on a dû définir une cible virtuelle qui appel un script bash qui compile le framework. Yeah...
Autre exemple, notre appli utilise le thème QtCurve qui est géré par CMake. Et là aussi, qmake ne gère pas cmake et on a du faire preuve de «créativité» pour que cela s'intègre à notre solution.
Donc voila, mon point est que qmake manque cruellement de flexibilité. Alors certes, certains pourraient nous reprocher de l’utiliser dans des cadres non prévus pour. Et j'ai presque envie d'être d'accord avec eux. Mais je considère qu'un moteur de production doit s'adapter à l'utilisateur et non l'inverse.
Concernant QBS, je ne l'ai utilisé que dans des projets persos. Pour l'instant, le seul truc que j'ai à lui reprocher est qu'il ne gère pas pas les «promogate» utilisé dans Qt Designer. Il n'arrive pas à trouver les .h de mes widgets custom. Ça se résous en ajoutant manuellement le dossier du projet courant et tant que dossier d'include. Pour moi, c'est une regression vue que qmake gérait ça nativement. Problème trouvé en convertissant un vieux projet .pro vers .qbs. Et manifestement, c'est un vieux problème.
[^] # Re: et qmake et qbs ?
Posté par jtremesay (site web personnel) . En réponse à la dépêche E.T. téléphone Meson. Évalué à 8.
Ceci est mon retour d'utilisateur de qmake en tant que développeur de logiciel propriétaire pour le milieu de la micro-électronique (ne me jetez pas la pierre, il faut bien payer son loyer...).
qmake marche bien pour gérer des projets C++/Qt «classique». Mais dès que tu veux faire des trucs «un peu exotique», c'est une vraie plaie dans le c**. Il faut se montrer très «créatif» dans les .pro et utiliser des fonctionnalités non documentées dont tu découvres l’existence dans le wiki de Qt ou sur des forums.
Un exemple concret. Notre logiciel utilise un framework tierce (FlexNet) pour gérer les licences et s'assurer que le client utilise notre outil dans les conditions prévus par le contrat qu'il a signé (notamment nombre d'instances du logiciel pouvant s'exécuter en parallèles et fonctionnalités du logiciel. Ce framework nous est fourni sous la forme d'une archive à décompresser, et exécuter un simple make dedans pour générer la bibliothèque à intégrer dans notre outil. Vu que nos clients utilisent diverses architectures et plateformes (essentiellement RHEL 5/6/7 en amd64, mais pas que), nous avons décidés (à tort ?) d'intégrer ce framework dans notre projet .pro sous forme de sous-projet source pourqu'il soit compilé automatiquement par notre système d'intégration continue pour les plateformes cibles. Et là, c'est le drame parce qu'il n'y a pas de moyen simple d'expliquer à qmake que ce sous-projet se compile avec un simple make et qu'il peut utiliser le résultat pour le linker à notre soft. Et on ne peut pas non plus créer un .pro spécifique à ce projet (du moins facilement, j'ai essayé plus d'une fois), parce que le make sus-nommé fait de la «magie» : il génère un exécutable qui va générer les .h/.so que l'on va utiliser (l'éditeur du framework a choisi la sécurité par l'obscurité. L’exécutable va générer une version obfusqué de toute leur tambouille interne, qui va être appelé par l'API à laquelle on a accès). Du coup, on a dû définir une cible virtuelle qui appel un script bash qui compile le framework. Yeah...
Autre exemple, notre appli utilise le thème QtCurve qui est géré par CMake. Et là aussi, qmake ne gère pas cmake et on a du faire preuve de «créativité» pour que cela s'intègre à notre solution.
Donc voila, mon point est que qmake manque cruellement de flexibilité. Alors certes, certains pourraient nous reprocher de l’utiliser dans des cadres non prévus pour. Et j'ai presque envie d'être d'accord avec eux. Mais je considère qu'un moteur de production doit s'adapter à l'utilisateur et non l'inverse.
Concernant QBS, je ne l'ai utilisé que dans des projets persos. Pour l'instant, le seul truc que j'ai à lui reprocher est qu'il ne gère pas pas les «promogate» utilisé dans Qt Designer. Il n'arrive pas à trouver les .h de mes widgets custom. Ça se résous en ajoutant manuellement le dossier du projet courant et tant que dossier d'include. Pour moi, c'est une regression vue que qmake gérait ça nativement. Problème trouvé en convertissant un vieux projet .pro vers .qbs. Et manifestement, c'est un vieux problème.