Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 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 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 gbdivers
Inactif https://www.developpez.com
Le 21/02/2012 à 2:15
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.
1  0 
Avatar de gbdivers
Inactif https://www.developpez.com
Le 23/02/2012 à 9:54
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]90188d1/a/a/a" />
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 : Sélectionner tout
1
2
3
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 : Sélectionner tout
make doc
mais on peut également demander à qmake de sytématique lancer cette étape avec la commande suivante dans le .pro :
Code : Sélectionner tout
PRE_TARGETDEPS = doc
1  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 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