IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Outils Discussion :

Adieu qmake, bienvenue qbs !


Sujet :

Outils

  1. #1
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    Août 2008
    Messages
    26 607
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2008
    Messages : 26 607
    Points : 188 574
    Points
    188 574
    Par défaut Adieu qmake, bienvenue qbs !
    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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.
    Vous souhaitez participer aux rubriques Qt (tutoriels, FAQ, traductions) ou HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  2. #2
    Membre actif
    Profil pro
    Inscrit en
    Juillet 2008
    Messages
    71
    Détails du profil
    Informations personnelles :
    Âge : 56
    Localisation : France

    Informations forums :
    Inscription : Juillet 2008
    Messages : 71
    Points : 288
    Points
    288
    Par défaut Qt succombe a la mode ?
    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...

  3. #3
    Membre expérimenté Avatar de Firwen
    Profil pro
    Inscrit en
    Juin 2009
    Messages
    472
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : Juin 2009
    Messages : 472
    Points : 1 587
    Points
    1 587
    Par défaut
    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 ?
    It's not a bug, it's a feature

  4. #4
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Points : 3 344
    Points
    3 344
    Par défaut
    Si j'ai bien compris, ce build system n'est utile qu'avec Qt?

  5. #5
    Membre éclairé Avatar de AuraHxC
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2006
    Messages
    652
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Industrie

    Informations forums :
    Inscription : Mai 2006
    Messages : 652
    Points : 683
    Points
    683
    Par défaut
    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.

  6. #6
    Membre éprouvé

    Profil pro
    Responsable logiciel
    Inscrit en
    Octobre 2010
    Messages
    223
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Responsable logiciel

    Informations forums :
    Inscription : Octobre 2010
    Messages : 223
    Points : 1 183
    Points
    1 183
    Par défaut
    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).

  7. #7
    Membre averti
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    99
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 99
    Points : 303
    Points
    303
    Par défaut
    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

  8. #8
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2008
    Messages
    832
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2008
    Messages : 832
    Points : 2 625
    Points
    2 625
    Par défaut
    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?

  9. #9
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Points : 3 344
    Points
    3 344
    Par défaut
    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)

  10. #10
    Membre confirmé

    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Février 2005
    Messages
    464
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : Industrie

    Informations forums :
    Inscription : Février 2005
    Messages : 464
    Points : 646
    Points
    646
    Par défaut
    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 ?
    Selso.
    Ingénieur/CdP développement systèmes embarqués &

  11. #11
    cedrix57
    Invité(e)
    Par défaut
    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 ?

  12. #12
    Inactif  


    Homme Profil pro
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Points : 15 620
    Points
    15 620
    Par défaut
    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.

  13. #13
    Membre confirmé

    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Février 2005
    Messages
    464
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : Industrie

    Informations forums :
    Inscription : Février 2005
    Messages : 464
    Points : 646
    Points
    646
    Par défaut
    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.
    Selso.
    Ingénieur/CdP développement systèmes embarqués &

  14. #14
    Inactif  


    Homme Profil pro
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Points : 15 620
    Points
    15 620
    Par défaut
    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.

  15. #15
    Membre expert Avatar de air-dex
    Homme Profil pro
    Inscrit en
    Août 2010
    Messages
    1 653
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations forums :
    Inscription : Août 2010
    Messages : 1 653
    Points : 3 773
    Points
    3 773
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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.
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  16. #16
    Inactif  


    Homme Profil pro
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Points : 15 620
    Points
    15 620
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 ?

  17. #17
    Membre expert Avatar de air-dex
    Homme Profil pro
    Inscrit en
    Août 2010
    Messages
    1 653
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations forums :
    Inscription : Août 2010
    Messages : 1 653
    Points : 3 773
    Points
    3 773
    Par défaut
    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) :

    Nom : Screenshot.JPG
Affichages : 317
Taille : 57,6 Ko
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  18. #18
    Inactif  


    Homme Profil pro
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Points : 15 620
    Points
    15 620
    Par défaut
    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) :
    Nom : Screenshot.JPG
Affichages : 317
Taille : 57,6 Ko
    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 - Visualiser dans une fenêtre à part
    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) :
    mais on peut également demander à qmake de sytématique lancer cette étape avec la commande suivante dans le .pro :

Discussions similaires

  1. Réponses: 0
    Dernier message: 01/09/2009, 13h10

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo