Adieu qmake, bienvenue qbs : Qt Building Suite, un outil déclaratif et extensible pour la compilation de projets Qt

Le 18/02/2012, par dourouc05, Responsable Qt & Web sémantique
Outil ô combien utile à tout développeur Qt... et pourtant ô combien détesté ! Il fonctionne bien, mais n'est pas la partie la plus maintenable de Qt. On a déjà exploré ce que tout remplaçant potentiel de qmake doit être à même de faire (et une liste de commentaires et questions à ce sujet). Notamment, toute une série d'outils actuellement disponibles ont été étudiés, aucun ne remplissait totalement ce cahier des charges (la discussion a bien continué pour Qt 5 sur la mailing list). C'est pourquoi un projet interne à l'équipe de développement de Qt a été lancé pour tester l'une ou l'autre idée, d'où un tout nouvel outil : la Qt Build Suite, qbs, à prononcer cubes.

C'est tout sauf qmake : pas de lien à la version de Qt, génération d'un graphe de compilation propre à partir de la description de haut niveau du projet, plus de génération de Makefile suivi d'un appel à make/nmake/gmake ou autre. En lieu et place, qbs agit comme un make parallèle, il appelle directement le compilateur, l'éditeur de liens et tout autre outil utile à la compilation du projet (à la manière de SCons ou Ant).

C'est un nouveau langage déclaratif : après QML, l'environnement Qt semble se mettre à la mode déclarative. En réalité, le langage utilisé par qbs est une version allégée de QML. Il fournit une représentation facile à utiliser pour l'EDI, tout en laissant la liberté d'écrire des expressions JavaScript. L'éditeur de fichier de projet devrait gérer lui-même toutes les listes de chaînes littérales et, pour les constructions plus compliquées, n'agir qu'en tant qu'éditeur de texte (ces expressions n'étant requises que si on a besoin de plus de puissance... et laissant alors littéralement tout faire, au vu de l'extensibilité). Par exemple :


Code :



1
2
files: ["foo.h", "foo.cpp", "main.cpp"]              // éditable par l'EDI automatiquement 
files: generateFileList().concat(['extra.cpp'])      // éditable uniquement à la main

Un premier exemple complet, l'habituel Hello World :

Code :



1
2
3
4
5
6
import qbs.base 1.0
 
CppApplication {
     name: "HelloWorld"
     files: "main.cpp"
}

Une description complète du langage est disponible dans la documentation.

C'est extensible : alors qu'on cherche à tout prix à éviter avec qmake de générer du code ou de compiler des ressources, qbs fournit une syntaxe pour écrire des règles de transformation de fichier d'un certain type en un autre. On peut appeler des programmes pour le faire (comme rcc) ou exécuter directement la transformation en JavaScript. L'exemple simplifié qui suit montre comment transformer des fichiers .pluginspec.in en .pluginspec (comme ceux utilisés pour Qt Creator) :

Code :



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Rule {
    ...
    prepare: {
        var cmd = new JavaScriptCommand();
        cmd.description = "generating " + FileInfo.fileName(output.fileName);
        cmd.qtcreator_version = product.module.qtcreator_version;
        cmd.sourceCode = function() {
            var inf = new TextFile(input.fileName);
            var all = inf.readAll();
            all = all.replace(new RegExp('\\\$\\\$QTCREATOR_VERSION(?!\w)', 'g'), qtcreator_version);
            var file = new TextFile(output.fileName, TextFile.WriteOnly);
            file.write(all);
            file.close();
        }
        return cmd;
    }
}

C'est rapide pour des compilations incrémentales : qbs voit le projet de loin, comme un seul bloc, il ne doit pas se forker pour les sous-dossiers. Même si seulement une partie du projet est déjà compilée, le graphe complet de compilation est pris en considération, il n'y a plus d'appel récursif (qui devrait absolument être évité). Cela a pour effet secondaire de rendre les compilations incrémentales très rapides.

En modifiant un script de benchmarking pour supporter qbs, on peut comparer make et qbs, respectivement, pour une compilation incrémentale :
real 0m4.076s
user 0m2.556s
sys 0m1.952s
real 0m0.843s
user 0m0.724s
sys 0m0.112s

Vous voulez déjà tester ? Les sources sont d'ores et déjà disponibles sur Gitorious. Actuellement, le projet est au stade expérimental, un terrain d'expérimentation pour de nouveaux concepts. qmake va encore résister un certain temps, personne ne sera forcé à abandonner qmake (bien que Qt va fort probablement passer à qbs dès que possible). Un point crucial reste à implémenter : l'adaptation à l'environnement de compilation (aussi appelée processus de configuration). Pour le moment, la seule manière de procéder est d'utiliser un outil externe qui génère un fichier JSON qui sera chargé par qbs. La solution envisagée actuellement est de rendre les tests de configuration utilisables par les modules (une implémentation qui ne sera donc plus entièrement déclarative, mais qui contiendra une bonne proportion de JavaScript).

Source : Qt Labs.

Les rubriques (actu, forums, tutos) de Développez


Poster une réponse Retrouver la discussion sur le forum

Avatar de Klaim Klaim
Membre Expert
le 20/02/2012
Je ne pense pas. CMake a du succès parcequ'il genère directement des fichiers spécifiques au build system voulu, tandis qu'ici il sagit de la même stratégie que Scons c'est à dire remplacer le build system.
Cela signifie que c'est l'IDE qui devra avoir un plugin ou une config pour pouvoir lire les fichiers de QBS et les interpreter correctement.

Quand a savoir quelle est la meilleure stratégie... Personnellement je prefere celle de CMake mais la syntaxe est rééllement problématique pour moi. Du coup je lorgne à mort sur Premake ces temps-ci... (c'est du lua)
Avatar de bizulk bizulk
Membre éclairé
le 20/02/2012
Mouais ... je demande à voir.
Est-ce que l'on va pas avoir encore une usine à gaz qui sera mal maintenue et qu'on changera pour avoir un nouveau truc à la mode, pour reprendre aller plus loin que ce qui s'est dit plus haut ?
Avatar de cedrix57 cedrix57
Membre du Club
le 21/02/2012
Dans le cadre d'un projet scolaire, je suis en train de développer un logiciel open source multiplatforme. Il utilise Qt ainsi que deux autres bibliothèques.

J’avoue que j'adore qmake et les fichier pro...mais le problème c'est qu'il me faut un fichier pro pour chaque système d'exploitation ou je compile mon logiciel car les bibliothèques/fichiers d'entête sont pas toujours au même endroit.

Je crois que faire des script ./configure est une solution à ce problème...mais quand j'ai compilé certains logiciels et vu la complexité j'ai même pas osé tenter de comprendre comment cela fonctionne.

Est ce que cet nouvel outil permettra de proposer une solution à ce problème ? C'est à dire générer le bon Makefile pour chaque système qui possède les dépendances requises ?
Avatar de gbdivers gbdivers
Responsable C++
le 21/02/2012
Beaucoup de chose à corriger...


Citation:





Envoyé par cedrix57


Dans le cadre d'un projet scolaire, je suis en train de développer un logiciel open source multiplatforme. Il utilise Qt ainsi que deux autres bibliothèques.

J’avoue que j'adore qmake et les fichier pro...mais le problème c'est qu'il me faut un fichier pro pour chaque système d'exploitation ou je compile mon logiciel car les bibliothèques/fichiers d'entête sont pas toujours au même endroit.

Je crois que faire des script ./configure est une solution à ce problème...mais quand j'ai compilé certains logiciels et vu la complexité j'ai même pas osé tenter de comprendre comment cela fonctionne.

Est ce que cet nouvel outil permettra de proposer une solution à ce problème ? C'est à dire générer le bon Makefile pour chaque système qui possède les dépendances requises ?



En fait, qmake le fait déjà. Il suffit d'utiliser des directives de compilation (par exemple win32: ou linux. qmake peut faire également des choses plus poussé, comme rechercher un fichier ou en vérifier l’existence.


Citation:





Envoyé par bizulk


Est-ce que l'on va pas avoir encore une usine à gaz qui sera mal maintenue et qu'on changera pour avoir un nouveau truc à la mode, pour reprendre aller plus loin que ce qui s'est dit plus haut ?



Plus maintenu ? Ce n'est pas quelque chose qui arrivera avec Qt.


Citation:





Envoyé par mangobango


Tout ça pour dire que je trouve que c'est dommage de ne pas avoir essayé d'améliorer l'existant (accélérer et étendre SCons, améliorer la syntaxe et les erreurs de CMake...) plutôt que de créer un nouvel outil qui vient s'ajouter à une ribambelle d'autres outils



C'est un point qui a été discuter longtemps pour qmake et qui le sera encore logtemps pour qbs. Il existe un post sur le Qt Labs pour expliquer ce choix, il faudrait que je le retrouve.
EDIT: trouvé, traduit en français par l'équipe de traduction de Developpez (qui recrute en permanence des traducteurs, pour ceux que ça pourrait interesser...)
http://qt-labs.developpez.com/compil...ke-et-au-dela/
http://qt-labs.developpez.com/compil...au-dela-redux/


Citation:





Envoyé par stef-13013
Voir le message

Pourquoi créer -encore- un outil alors qu'il en existe déjà et des biens !?
Cmake, Ant, etc... bien sur il ne seront jamais aussi bien intégré, mais bon...



C'est toujours la même raison avec Qt : fournir un système unique qui fonctionne sur toutes les plateformes supportées par Qt.
Un news récente parle de VxWorks, est-ce que ces outils fonctionnent dessus ? Et sur les autres plateformes ?
En fournissant son propre outils de compilation, Qt garantie aux utilisateurs d'avoir un seul outils pour tout faire et n'est pas dépendant des autres outils.
Avatar de bizulk bizulk
Membre éclairé
le 21/02/2012

Citation:




C'est toujours la même raison avec Qt : fournir un système unique qui fonctionne sur toutes les plateformes supportées par Qt.
Un news récente parle de VxWorks, est-ce que ces outils fonctionnent dessus ? Et sur les autres plateformes ?
En fournissant son propre outils de compilation, Qt garantie aux utilisateurs d'avoir un seul outils pour tout faire et n'est pas dépendant des autres outils.


Oui si effectivement il est prouvé que :
reprendre tel ou tel outil pour le porter aux autres plateforme remettrait en cause ses fondements et obligerait de le reprendre à zéro.

Ce n'est pas parce qu'il n'y a pas de support officiel qu'un portage est impossible.

Désolé mais je vois trop souvent des gens dire ou ne pas dire plutôt, ben non on a pas envie de passer du temps a comprendre ce que tu as fais, ou ton style d'écriture ne me convient pas je préfère faire un truc dans mon coin, pour arriver au même problème.

J'ai lu plus haut que l'on reprochait à qmake d'être mal maintenue, mais je ne confirme pas que c'est le cas. Je m'en sers assez simplement donc je n'ai jamais pu en rencontrer les limites. Sinon que lui reproche-t-on vraiment ? Il faudrait que je scrute ces listes.
Avatar de gbdivers gbdivers
Responsable C++
le 21/02/2012

Citation:





Envoyé par bizulk
Voir le message

Oui si effectivement il est prouvé que :
reprendre tel ou tel outil pour le porter aux autres plateforme remettrait en cause ses fondements et obligerait de le reprendre à zéro.
Ce n'est pas parce qu'il n'y a pas de support officiel qu'un portage est impossible.



Je comprends ton sentiment. On reproche souvent à Qt d'être très atteint du syndrome NIH. C'est un sujet très trollesque, avec des discussions à ne plus finir (voir par exemple la critique du QObject sur le forum C++).


Citation:





Envoyé par bizulk
Voir le message

Désolé mais je vois trop souvent des gens dire ou ne pas dire plutôt, ben non on a pas envie de passer du temps a comprendre ce que tu as fais, ou ton style d'écriture ne me convient pas je préfère faire un truc dans mon coin, pour arriver au même problème.



Ce n'est pas totalement vrai pour Qt puisque les devs ont écrit des articles pour utiliser Qt avec d'autres outils de compilation (par exemple cmake dans cet article). Donc ils connaissent les autres outils. C'est bien un choix délibéré et pas de la paresse.


Citation:





Envoyé par bizulk
Voir le message

J'ai lu plus haut que l'on reprochait à qmake d'être mal maintenue, mais je ne confirme pas que c'est le cas. Je m'en sers assez simplement donc je n'ai jamais pu en rencontrer les limites. Sinon que lui reproche-t-on vraiment ? Il faudrait que je scrute ces listes.



Ca devient compliqué lorsque l'on a une architecture complexe (plusieurs libs + des exe + des tests unitaires) avec différentes options de compilation, pleins de répertoires, etc.
Avatar de air-dex air-dex
Membre Expert
le 22/02/2012

Citation:





Envoyé par gbdivers
Voir le message


Citation:





Envoyé par cedrix57
Voir le message

Dans le cadre d'un projet scolaire, je suis en train de développer un logiciel open source multiplatforme. Il utilise Qt ainsi que deux autres bibliothèques.

J’avoue que j'adore qmake et les fichier pro...mais le problème c'est qu'il me faut un fichier pro pour chaque système d'exploitation ou je compile mon logiciel car les bibliothèques/fichiers d'entête sont pas toujours au même endroit.

Je crois que faire des script ./configure est une solution à ce problème...mais quand j'ai compilé certains logiciels et vu la complexité j'ai même pas osé tenter de comprendre comment cela fonctionne.

Est ce que cet nouvel outil permettra de proposer une solution à ce problème ? C'est à dire générer le bon Makefile pour chaque système qui possède les dépendances requises ?


En fait, qmake le fait déjà. Il suffit d'utiliser des directives de compilation (par exemple win32: ou linux. qmake peut faire également des choses plus poussé, comme rechercher un fichier ou en vérifier l’existence.
Après ça dépend de ce que tu gardes d'une plateforme à l'autre. Si tu veux utiliser les mêmes fichiers jusqu'au Projet.pro.user de Creator et conserver les binaires que tu compiles. Mais sinon +1 à gbdivers tout en sachant que tu peux faire pour chacune des plateformes des trucs du style : Projet.windows.pro (ou Projet.linux.pro ou Projet.mac.pro) :
Code :
include(Projet.pri) # Fichier projet multi-plateforme comme décrit par gbdivers

Je l'ai déjà fait avec plusieurs projets Qt (sur Windows et Linux) et Creator ne râle pas à l'ouverture. Il suffit de créer un projet "Projet" avec l'IDE (Qt Creator t'insulte si tu crées un projet avec un '.' dans le nom à partir de son wizard) et de renommer Projet.pro et Projet.pro.user en Projet.plateforme.pro et Projet.plateforme.pro.user en dehors de Qt Creator. Tu pourras ensuite travailler sur le projet "Projet.plateforme" avec Qt Creator sans te faire insulter par l'IDE.
Avatar de gbdivers gbdivers
Responsable C++
le 22/02/2012

Citation:





Envoyé par air-dex
Voir le message

Après ça dépend de ce que tu gardes d'une plateforme à l'autre. Si tu veux utiliser les mêmes fichiers jusqu'au Projet.pro.user de Creator et conserver les binaires que tu compiles. Mais sinon +1 à gbdivers tout en sachant que tu peux faire pour chacune des plateformes des trucs du style :

Projet.windows.pro (ou Projet.linux.pro ou Projet.mac.pro) :

Code :



include(Projet.pri) # Fichier projet multi-plateforme comme décrit par gbdivers

Je l'ai déjà fait avec plusieurs projets Qt (sur Windows et Linux) et Creator ne râle pas à l'ouverture. Il suffit de créer un projet "Projet" avec l'IDE (Qt Creator t'insulte si tu crées un projet avec un '.' dans le nom à partir de son wizard) et de renommer Projet.pro et Projet.pro.user en Projet.plateforme.pro et Projet.plateforme.pro.user en dehors de Qt Creator. Tu pourras ensuite travailler sur le projet "Projet.plateforme" avec Qt Creator sans te faire insulter par l'IDE.



Je n'ai pas très bien compris. Pourquoi faire des .pro pour chaque plateforme qui appellent un .pri qui gère le multiplateforme plutôt que faire directement 1 seul .pro qui gère le multiplateforme ?
Avatar de air-dex air-dex
Membre Expert
le 23/02/2012

Citation:





Envoyé par gbdivers
Voir le message

Je n'ai pas très bien compris. Pourquoi faire des .pro pour chaque plateforme qui appellent un .pri qui gère le multiplateforme plutôt que faire directement 1 seul .pro qui gère le multiplateforme ?



Tu peux te servir du ".plateforme.pro.user" (si tu travailles avec Creator) pour automatiser dans Creator des processus autour de ton programme qui dépendraient de la plateforme (génération de documentation et de fichiers de traductions par exemple). Un peu comme ça (génération de documentation via Doxygen) :

[ATTACH]90188[/ATTACH]
Avatar de gbdivers gbdivers
Responsable C++
le 23/02/2012

Citation:





Envoyé par air-dex
Voir le message

Tu peux te servir du ".plateforme.pro.user" (si tu travailles avec Creator) pour automatiser dans Creator des processus autour de ton programme qui dépendraient de la plateforme (génération de documentation et de fichiers de traductions par exemple). Un peu comme ça (génération de documentation via Doxygen) :
[ATTACH]90188[/ATTACH]


Le question avait déjà été abordé : les fichiers .pro.user sont des fichiers de travail de Qt Creator (une sorte de fichier de cache) et sont spécifiques pour une plateforme mais également pour une configuration particulière. Ils ne sont pas destinés à être partagés avec le projet. En plus, c'est une source d'erreur car en cas de mise à jour d'une des libs utilisées (en particulier de Qt), les répertoires indiqués dans le .pro.user ne seront peut être plus valide et les utilisateurs auront soit un message d'erreur incompréhensible, soit ils auront à forcer la compilation et les paramètres spécifiques dans le .pro.user seront perdu. La bonne (et unique) façon de faire est de configurer correctement le .pro. Pour ajouter la compilation de la doc par exemple, il faut ajouter une target spécifique dans le .pro :
Code :
123
doc.target = doc
doc.commands = doxygen .    # à modifier avec tes propres paramètres pour doxygen
QMAKE_EXTRA_TARGETS += doc

On lance en général la compilation des cibles supplémentaires manuellement pour ne pas perdre de temps à mettre à jour de la doc en dev avec la ligne de commande (dans le cas de la doc) :

Code :



make doc

mais on peut également demander à qmake de sytématique lancer cette étape avec la commande suivante dans le .pro :

Code :



PRE_TARGETDEPS = doc

 
 
 
 
Partenaires

Hébergement Web