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

Le , par dourouc05

0PARTAGES

4  0 
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 : Sélectionner tout
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 : Sélectionner tout
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 : Sélectionner tout
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.

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de stef-13013
Membre actif https://www.developpez.com
Le 19/02/2012 à 12:34
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...
0  1 
Avatar de Firwen
Membre expérimenté https://www.developpez.com
Le 19/02/2012 à 14:37
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...
Parce que tous les builds systèmes existant, spécialement les C/C++ ont tous leurs défauts, et que ça peut pas faire de mal de tenter d'en faire un nouveau.

SCons a la rapidité d'une tortue asthmatique en plein Sahara dés que le projet prend de l'envergure.

Les Autotools sont une magnifique usine à gaz mixant du perl, des macros m4, du bash et du code natif héritant de 15 ans de compatibilité ( sérieusement, qui maîtrise réellement libtool ?! ).

CMake a sa syntaxe tordu, ses variables vides qui causent des erreurs silencieuses, et est loin d'etre réellement extensible pour les nouveaux langages.

Waf a une api qui change tous les 15 jours et nécessite un bac +8 pour être utilisé correctement....

Je continue ?
2  0 
Avatar de Klaim
Membre expert https://www.developpez.com
Le 19/02/2012 à 15:29
Si j'ai bien compris, ce build system n'est utile qu'avec Qt?
0  0 
Avatar de AuraHxC
Membre éclairé https://www.developpez.com
Le 19/02/2012 à 16:28
Citation Envoyé par Klaim Voir le message
Si j'ai bien compris, ce build system n'est utile qu'avec Qt?
Effectivement cela m'intéresse de savoir si il est possible de l'utiliser comme on le veut... Parce que j'utilise CMake pour la totalité de mes projets, y compris les projets Qt, donc si cela ne sert que pour Qt, cela va malheureusement pas me concerner et pas m'intéresser plus que ça.
0  0 
Avatar de idiallo
Membre éprouvé https://www.developpez.com
Le 19/02/2012 à 17:27
Citation Envoyé par AuraHxC Voir le message
Effectivement cela m'intéresse de savoir si il est possible de l'utiliser comme on le veut... Parce que j'utilise CMake pour la totalité de mes projets, y compris les projets Qt, donc si cela ne sert que pour Qt, cela va malheureusement pas me concerner et pas m'intéresser plus que ça.
Non qbs est indépendant de Qt (cf http://labs.qt.nokia.com/2012/02/15/...#comment-69079).
0  0 
Avatar de mangobango
Membre averti https://www.developpez.com
Le 19/02/2012 à 23:35
Hum,

J'aime bien les sources qui se compilent quasiment toutes seules sans rien. Je peux par exemple bootstrapper Boost avec un script fourni qui va compiler BJam avec le compilo qu'on lui dit d'utiliser et boum! J'ai Boost. Ce script de bootstrap utilise Batch sous windows, Bash sous les autres OS il me semble. J'ai donc besoin du code source de Boost et du compilo, et hop!

Bon, c'est assez éloigné du "DRY" puisqu'il faut se retaper le script de boostrap. A moins que celui-ci ne soit réutilisable. Un genre de librairie. Un genre de gestionnaire de compile. Un make quoi, ou un BJAM. Je sais, c'est le serpent qui se mord la queue.

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 (il ne faut pas rêver de trop : il ne va jamais supplanter tous les autres outils de build - il va cohabiter). Ayant dû gérer simultanément plusieurs systèmes de build pour compiler toutes les dépendance d'un projet, je vois QBS comme un potentiel poil à gratter supplémentaire... même si c'est sans doute très bien comme outil. Je me dis simplement : "roh prout, encore un autre outil qui va un jour devoir être pris en charge dans notre ultra-bazar, avec sa syntaxe bien à lui" et ça fait un peu déprimer!

Voilà, intéressant non?
Daniel
1  0 
Avatar de Freem
Membre émérite https://www.developpez.com
Le 20/02/2012 à 16:51
Cela signifie t-il que qt sera moins pénible à gérer avec un IDE qui n'est pas prévu pour nativement?
La dernière fois que j'ai essayé d'intégrer proprement ce framework à codeblocks, j'ai simplement fini par abandonner après pas mal d'heures...

Si cet outil remplace directement le compilateur plutôt que d'ajouter une étape dans la chaîne de compilation, ça devrait être un chouïa plus simple à gérer pour l'utilisateur, non?
0  0 
Avatar de Klaim
Membre expert https://www.developpez.com
Le 20/02/2012 à 19:04
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)
0  0 
Avatar de bizulk
Membre confirmé https://www.developpez.com
Le 20/02/2012 à 22:21
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 ?
0  0 
Avatar de
https://www.developpez.com
Le 21/02/2012 à 0:57
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 ?
0  0 
Responsable bénévole de la rubrique Qt : Thibaut Cuvelier -

Partenaire : Hébergement Web