QMake et au-delà, le retour

| Marius | Qt Labs |

Traducteur

Louis du Verdier

L'article précédent, sur le site officiel, a engendré un grand nombre de réponses constructives. Ainsi, pour répondre aux suggestions des intéressés, l'auteur a décidé de publier une réponse sous la forme d'un nouvel article, présentant qu'il serait dommage de se limiter à de simples réponses par le biais du système de commentaires.

N'hésitez pas à commenter cet article !
Commentez

- Titre : QMake et au-delà, le retour

- Auteurs : Marius, Qt Labs

- Traducteur : Louis du Verdier

- Parution : 20 octobre 2010

- Mise à jour : 1 février 2020

- Licence : Copyright ® 2010 Marius. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. L'article original

- II. Introduction

- III. Questions et réponses

- IV. Conclusion

I - L'article original

Qt Labs est un site géré par les développeurs de Qt. Ils y publient des projets, des idées propres et des composants afin d'obtenir les retours d'informations sur les API, le code et les fonctionnalités ou simplement pour partager avec nous ce qui les intéresse. Le code que vous y trouverez peut fonctionner tel quel, mais c'est sans aucune garantie ni support.

Nokia, Qt, Qt Labs et leurs logos sont des marques déposées de Nokia Corporation en Finlande et/ou dans les autres pays. Les autres marques déposées sont détenues par leurs propriétaires respectifs.

Cet article est la traduction de l'article To make, or not to make – QMake and beyond: Redux, par Marius paru dans Qt Labs.

II - Introduction

L'entrée de blog précédente, hier, a engendré tant de commentaires constructifs que j'ai senti qu'elle ne pouvait simplement recevoir une réponse dans les commentaires. Ainsi, dans cette entrée se situent des réponses et des commentaires concernant vos remarques, que vous pouvez commenter à nouveau.

Note du traducteur : dans le titre, make semble correspondre à l'outil make et non au verbe, d'où une troncature du titre.

L'article est lié à de nombreux éléments, dont les plus importants sont les suivants :

- la documentation de QMake ;

- l'article précédent : QMake et au-delà.

III - Questions et réponses

De nombreuses personnes : « Avez-vous considéré le système de compilation {insérez votre favori ici} ? »

Oui, nous l'avons fait.

Tout système basé sur Java est automatiquement /ignored à cause du coût de l'exécution d'un tel système et du fait que nous nécessiterions alors une exécution de Java VM sur tous les systèmes que nous supportons. Un système de compilation doit être rapide et peu coûteux.

Nous ne considérons pas réellement les outils automatiques.

Max : « CMake obtient beaucoup de commentaires du style de « Woaw ! C'est super ! », mais je peux écrire de nombreux posts de blog concernant la raison pour laquelle il est en fait tout simplement médiocre. Je peux deviner que vous êtes d'accord puisque vous ne le prenez pas en considération. »

C'est incorrect. Nous n'avons jamais dit ni laissé entendre que nous ne prenons pas CMake en compte. Actuellement, CMake peut sans doute ne pas combler notre liste complète de souhaits, mais nous l'avons bien sûr toujours pris en considération. En effet, nous avons lancé des discussions avec KitWare (les gars derrière CMake) des semaines avant la publication de cette entrée de blog, notamment pour savoir si nos vœux pouvaient être unis avec leurs projets pour CMake. Ces discussions sont toujours en cours. En effet, Bill Hoffman (CTO et vice-président de KitWare) est actuellement aux DevDays à Munich, où ces discussions vont continuer.

nathan : « Je pense que l'idée d'utiliser le JavaScript a un grand nombre d'avantages »

Sylvain : « JavaScript + JSON est une combinaison vraiment excellente, n'hésitez pas à vous penchez dessus ! »

Damien Arthur : « Un outil de génération basé sur JSON serait intéressant. »

Adam Higerd : « J'aime l'idée d'utiliser la notation ECMAScript/JSON. C'est simple et pas trop bavard, mais suffisamment expressif pour gérer les modes non triviaux. »

mariuz : « Je choisirais JavaScript ou un Python minimal (quelque chose de la sorte). »

spinynorman : « S'il vous plait, ne basez aucun remplacement sur JavaScript. […] Votre cible principale est constituée de développeurs plus à l'aise dans la programmation d'applications bureautiques que dans les langages Web. Je verrais plutôt cela sur une base Python que sur une base JavaScript. »

Tim : « Je pense que l'intégration à l'EDI est le facteur le plus important à prendre en considération, et surtout que vous ne pouvez pas bien faire si votre fichier de génération est un script. »

Après avoir énormément réfléchi sur les systèmes de génération, nous avons tendance à apprécier l'idée d'utiliser JavaScript comme langage de génération. Les raisons sont les suivantes :

- JavaScript permet d'utiliser un langage impératif et un sous-ensemble de syntaxe déclarative (JSON). C'est parfait pour le support des EDI, puisqu'on peut dire qu'un projet est premièrement défini dans la syntaxe déclarative, tout en continuant à supporter des générations plus complexes utilisant un langage entièrement impératif. L'EDI supporte alors uniquement la modification du JSON du projet et donc le support des changements de drapeaux de compilateur, des defines, de l'ajout et du retrait de fichiers sous des plateformes diverses et variées, etc. et pour les parties non déclaratives, il peut vous laisser dans un éditeur coloré syntaxiquement avec un accès aisé à la documentation ;

- pas besoin de compter sur un élément tiers. JavaScriptCore peut être autonome dans le produit, donc il n'y a pas besoin d'une distribution tierce. Cela permet aussi de structurer plus l'usage du langage, aussi vrai que vous n'exposeriez pas une usine chargée de bibliothèques par défaut, que vous auriez par exemple avec Python ;

- vitesse native sous de nombreuses plateformes : JavaScriptCore compilera les scripts dans un code natif sous de nombreuses plateformes et, de plus, l'exécution du script sera rapide ;

- des bons outils de débogage pour JavaScript : JavaScript possède un grand nombre de débogueurs facilement accessibles pour cela, il est donc possible de déboguer le processus complet de génération depuis l'EDI, par exemple ;

- base d'utilisateur solide, et croissante : l'usage du JavaScript sur la Toile est en train de croître à un rythme effréné. Le langage de script de QML est le JavaScript. Ainsi, dans une équipe, il y aura toujours quelqu'un qui connaîtra déjà le langage. Cela rend la maintenance du système de génération d'autant plus simple, à la fois pour nous et pour les utilisateurs.

Peter : « Ce n'est pas trop dur d'utiliser CMake avec QtScript, regardez donc ceci : http://sourceforge.net/projects/cmakescript/ ! Un hello world ressemble à cela : »

project("hello")

// this starts the debugger
// Qt 4.5 needed
debugger

var name = "Hello";

add_library (name, "hello.cxx")

C'est une pure preuve du concept et je pourrais définitivement considérer CMake avec du langage JavaScript. Cependant, à moins que vous ne commenciez le changement de quelques internes pour rendre l'utilisation du langage plus efficace, alors tout ce que vous avez est un nouveau langage utilisé de la même manière qu'avant, tel que le montre l'appel de la fonction add_library() ci-dessus. Si les internes sont modifiées pour permettre la construction de projet JSON, alors nous pourrons en reparler ! Ce projet est bon, mais, à son stade actuel, pas tellement plus avancé que ce que nous avions avec QMake combiné avec JavaScript, que nous avions également avant (d'ailleurs, je ne suis pas sûr que KitWare veuille intégrer complètement le module QtScript dans CMake ).

DAVIDB : « CMake – c'est suffisamment bien pour KDE qui gère plus ou moins un billion de lignes dans des centaines de milliers de projets. Il est là depuis un certain temps, et il a prouvé qu'il est un très bon outil de configuration cross-plateforme. »

De nombreuses caractéristiques nécessitaient des implémentations avant que le projet KDE puisse utiliser CMake et seraient d'autant plus nécessaires pour le support de Qt. Ce n'est pas juste un problème de caractéristiques manquantes, mais aussi de langage. Nous aimons QMake dans le sens où il est pratique pour les projets d'ampleur moyenne, bien qu'il puisse devenir horrible lorsque l'on passe à des projets d'ampleur moyenne aux projets complexes. C'est d'ailleurs très rapide de prendre la main sur QMake. Souvent, on a juste à exécuter qmake -project dans notre dossier de projet et on a finalement un fichier .pro qui nous convient la plupart du temps, si ce n'est tout le temps.

Vous devez également tenir compte de tous les utilisateurs que Qt a actuellement, ainsi que ceux qu'il aura par la suite, tout en gardant en tête qu'il faut aussi faire évoluer le portage vers les téléphones portables. Toute décision de notre part poussera à un moment ou à un autre les gens à changer, bien que nous ayons bien sûr décidé de continuer encore un peu le maintien de QMake.

Coder : « Pourquoi ne pas prendre un système de génération cross-plateforme open source et y contribuer ? »

Si nous trouvons un projet qui fait correctement le pont entre la liste de nos vœux et les nécessités que nous avons, alors bien sûr, ce sera ce que nous ferons. Nous ne souhaitons pas réinventer la roue, si possible. Cependant, nous avons des raisons solides de ne pas sauter sur le premier système qui, dans son état actuel, a été sujet à des discussions ; c'est d'ailleurs pour cela que nous vous tendons la perche : afin de savoir ce que vous pensez des outils divers et variés, ainsi que de QMake, bien sûr.

spinynorman : « Quoi que vous fassiez, ce serait extrêmement gentil de fournir une méthode simple d'upgrade : un moyen d'importer les fichiers .pro de QMake de l'ancien au nouveau système. »

Pour nous, les utilisateurs sont toujours une priorité et nous ferons bien sûr au mieux pour vous simplifier la tâche lors de la transition. Tout comme le support de Qt 3 a été gardé jusqu’à présent, peut-être qu'un nouvel outil pourrait remplacer QMake ? Ce n'est pas impossible.

spinynorman : « Surtout, ne concevez pas de comportement caché tel qu'une inclusion spéciale ou des chemins de bibliothèques (tel que les chemins de bibliothèques que QMake lui-même décide d'ajouter aux Makefiles). »

Je crains que vous ne soyez en train d'utiliser QMake d'une manière incorrecte, si c'est l'addition de chemins de bibliothèques que vous ne voulez pas dans vos Makefiles. Par exemple, si vous voulez utiliser QMake pour des projets n'étant pas des projets Qt, vous devrez ajouter la ligne CONFIG -= qt dans votre .pro.

spinynorman et de nombreuses personnes : « QMake ne pourrait-il pas être corrigé plutôt que remplacé ? »

C'est possible. Toutefois, le fait de changer les internes tout en conservant la compatibilité demanderait des efforts considérables, et au point où en sont les tests automatiques de QMake, personnellement, je ne le ferais pas. Pourtant, je peux supposer que cela serait faisable si suffisamment de monde considérait cette idée comme un meilleur choix par rapport à un tout nouvel outil. Une question se pose alors : comment corriger les erreurs du langage sans détruire trop de projets ? En rapatriant le module Qt Script dans QMake ?

Holger Schurig : « Si vous considérez l'utilisation de votre propre outil, faites-en une bibliothèque, de manière à ce que l'intégration dans les EDI soit aisée. »

Si nous décidons d'écrire notre propre outil, ça serait l'idée, en effet. La bibliothèque contiendrait le DAG complet, des fonctions pour manipuler les JSON du projet et l'EDI pourrait parcourir les nœuds invalidés du DAG, tout comme il pourrait compiler et actualiser le compétiteur de code.

Holger Schurig : « QMake a actuellement de nombreux générateurs, par exemple pour Unix, make, et pour Windows, nmake. Peut-être qu'il pourrait obtenir un générateur, QBuilder (peu importe le nom qu'il aurait). Cela permettrait d'utiliser QMake pour convertir un projet QMake en projet QBuilder. »

C'est une idée originale. Le seul problème est que de nombreux projets sont « perdus en conversion ». L'analyse faite, une grande partie des informations est perdue (vérifications système, conditions, boucles, etc.), donc les informations que le back-end voit deviendront uniquement valides pour une configuration particulière.

Reed : « Jam (Boost Jam ou Perforce) est très bien ! »

Je vous conseille la lecture de cet article : http://gamesfromwithin.com/the-quest-for-the-perfect-build-system-part-2

Cliff : « Ecmascript-Syntax est mieux que tout langage étrange, bien qu'à mes yeux, il ne fixe pas entièrement le problème des EDI. Les EDI pourraient-ils évaluer le code ? »

Comme mentionné plus haut, si le système de génération est mis sous forme de bibliothèque, l'EDI devrait contenir sa logique complète, son analyseur et son DAG, et ce, de manière à ce qu'il puisse, si besoin, analyser de nouveau le fichier de projet et remplacer la branche concernée dans le DAG. Les systèmes parcourant le DAG pourraient ainsi s'occuper de la nouvelle génération des nœuds invalides.

Craig Ringer : « CMake semble bien… lors d'une première étude. Comme la plupart des systèmes de génération, il s'avère avoir de grosses verrues repoussantes. »

Tout système de compilation aura aux yeux des gens ces « verrues repoussantes ». QMake en a sans doute quelques-unes. La clé est la façon de les traiter (faire des rapports et envoyer des patchs) et la façon de les gérer de l'équipe maintenant l'outil. C'est OK si un outil a des « verrues » jusqu'à ce que : a) vous ayez un contournement possible ; b) vous puissiez vous occuper du problème, et/ou ; c) l'équipe tente activement de fixer ces problèmes. Je suis certain que KitWare n'aime pas avoir des « verrues » dans ses produits et essaie activement de les résoudre.

Craig Ringer, (toujours à propos de CMake) : « J'ai eu à copier presque tous les standards du module de recherche que j'ai utilisé dans mon arbre de sources, et j'ai eu à le modifier pour gérer un ou plusieurs problèmes basiques – la dissimulation de résultats négatifs, d'échecs de la gestion des bibliothèques de linkage sous win32, d'échecs pour gérer les espaces dans les chemins, etc. »

… Et je suppose que vous avez contribué en fournissant ces patchs à KitWare, non ?

Craig Scott : « La cross-compilation : je préfère amplement compiler sur la plateforme elle-même. Dès que vous avez à intégrer un pack tiers qui nécessite d'être installé pour fournir des éléments de la génération (par exemple, des bibliothèques, des fichiers d'en-tête, etc.), la tentative de monter une cross-compilation devient très compliquée. »

Malheureusement, c'est une réalité que nous (Qt) devons de plus en plus supporter. Quand nous commençons à cibler des systèmes embarqués, des téléphones, etc., nous devons souvent faire des cross-compilations mixées. Heureusement, peu de monde nécessite de passer par là.

Uwe : « À mon avis, il serait plus important d'avoir une documentation plus complète de QMake plutôt qu'un nouvel environnement de génération. »

Florian : « Je suis fermement pour la réécriture de QMake et pour rester compatible (!). Cela signifie essentiellement que vous devez écrire un test unitaire pour les fonctionnalités existantes de QMake, et que vous devez garder cela lors de la refactorisation.  […] Dans notre compagnie, nous avons des milliers de profils QMake et cela serait une très mauvaise idée pour nous que vous stoppiez QMake ! »

QMake a certainement de nombreuses propriétés non documentées qui devraient l'être. Cependant, notre organisation arrive aux limites de ses capacités et de la maintenabilité, donc nous trouvons difficile de continuer en l'état actuel des choses. Soit nous rénovons sérieusement QMake, en fixant ses internes et en reprenant en main le langage, soit nous passons à un autre outil que nous tentons de prendre en main. Je peux supposer que la plupart des utilisateurs actuels de Qt attendent de nous de partir sur la première solution, mais la question est alors la suivante : cela demandera-t-il trop de ressources ? Et dans quelles perspectives temporelles ?

Per : « Tentez d'apprendre des terribles erreurs de QMake, si vous partez dessus. En particulier, permettez l'interface simple et habituelle de notre cher ./configure pour un changement avec une documentation intégrée. »

Cela a fait l'objet d'une discussion avec KitWare.

Chris : « Que pensez-vous d'une approche basée sur le XML, comme le fait Ant ? »

Le XML est trop bavard et impossible à maintenir à la main. D'ailleurs, de nombreux utilisateurs de Qt n'utilisent pas un GUI pour le développement et détestent avoir à maintenir des fichiers XML pour la génération.

cartman : « http://code.google.com/p/gyp/ pourrait répondre à tous vos problèmes. »

Il possède la partie JSON, oui, mais il manquera légèrement de propriétés de projet si nous décidons de partir avec quelque chose d'établi.

Sebastian : « Il y a longtemps, j'ai regardé QMake et j'ai à ce moment-là cru qu'il ne pouvait pas créer des projets VS pleinement développés qui permettent d'utiliser toutes les définitions usuelles de l'EDI, mais juste des wrappers projets infirmes appelant uniquement nmake, manquant donc des définitions usuelles. »

Je dois juste répondre à cela, puisque j'ai écrit entièrement le générateur vcproj/sln : QMake n'a jamais créé de simple wrapper de nmake pour les projets VS. La première version du générateur vcproj analysait toutes les options connues à la fois et les plaçait la plupart du temps de manière correcte dans le format d'un projet VS.

QtFan : « Cela m'intrigue : quand vous avez commencé à parler d'un changement/remplacement de QMake, y a-t-il eu des intentions du changement/extension du MOC ? »

Le MOC est un sujet différent et non, nous ne comptons pas le changer. L'étendre, peut-être. Donnez-nous un cas d'usage détaillé et nous vous en parlerons.

Florian : « Je pense que si vous créez un nouvel outil, nous ne l'utiliserons pas dans nos compagnies et nous le remplacerons par CMake, parce que CMake ne s'en ira jamais. »

Il n'y a pas de raison que QMake s'en aille. Il est open source, après tout.

gwright : « Personnellement, je pense que QMake est parfait. Cependant, il a un énorme défaut qui est un rédhibitoire, pour moi du moins […] les backends du générateur de makefiles de QMake sont couplés avec des versions spécifiques de linkers. »

Oui, c'est en partie vrai. Toutefois, ce n'est pas impossible à fixer et nous avons intérieurement un développeur qui tente de cross-compiler Qt pour Windows sur sa machine virtuelle Linux utilisant MinGW, et qui tente de lancer le résultat directement depuis son image de VMWare. L'application marche actuellement, mais manque de visuel.

IV - Conclusion

Cet article consistait donc à répondre à vos commentaires. Soyez prêts à commenter, nous voulons connaître vos avis !

Merci à johnlamericain pour son aide et ses encouragements lors de la traduction, à dourouc05 pour ses conseils et sa relecture ainsi qu'à jacques_jean et gbdivers pour leur relecture !

Au nom de toute l'équipe Qt, j'aimerais adresser le plus grand remerciement à Nokia pour nous avoir autorisé la traduction de cet article !