[Compilation] Adieu qmake, bienvenue qbs !

[dourouc05]

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.

[stef-13013]

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...

[Firwen]

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 ?

[Klaim]

Si j'ai bien compris, ce build system n'est utile qu'avec Qt?

[AuraHxC]

Envoyé par Klaim

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.

[idiallo]

Envoyé par AuraHxC

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).

[mangobango]

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

[Freem]

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?

[Klaim]

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)

[bizulk]

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 ?

[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 ?

[gbdivers]

Beaucoup de chose à corriger...

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.

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.

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/

Envoyé par stef-13013

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.

[bizulk]

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.

[gbdivers]

Envoyé par bizulk

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++).

Envoyé par bizulk

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.

Envoyé par bizulk

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.

[air-dex]

Envoyé par gbdivers

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.

[gbdivers]

Envoyé par air-dex

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 ?

[air-dex]

Envoyé par gbdivers

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) :

Screenshot.JPG

[gbdivers]

Envoyé par air-dex

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) :
Pièce jointe 90188

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 :

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 :

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