Qt organisation des fichiers et tests

Version imprimable

23/01/2022, 15h17
baragouine

Qt organisation des fichiers et tests

Bonjour,

On débute un projet sous Qt avec Git,

pour l'instant dans notre dépot git on a un répertoire doc/. On aimerait placer les sources dans un répertoire src/ mais on y arrive pas avec Qt Creator, de plus on aimerait ajouter des testes pour l'intégration continue mais Qt Creator ne permet que de créer un nouveau projet pour les testes. On aimerait intégré les testes dans le même répertoire que les sources du projet.
On bloque dessus, on aimerait un truc pro si vous pouviez nous aider ça serait sympa.

On veut juste savoir comment organiser nos fichiers de manière pro et ou mettre les testes et comment.

Citation:

Envoyé par baragouine

Bonjour,

On débute un projet sous Qt avec Git,

1- J'espère que vous ne voulez pas apprendre le C++ à partir de Qt, car ce n'est qu'un framework, qui a ses propres habitudes, qui divergent parfois de ce qui se fait "correctement" en C++, et qui ne vous apprendra pas les base ;) Mais bon, ce n'est qu'un détail :D

2- C'est très bien d'utiliser Git. Seulement, ce n'est qu'un gestionnaire de versions concurrentes, c'est à dire qu'il permet à plusieurs personnes de travailler potentiellement sur les mêmes fichiers (à condition de s'organiser correctement). Cela n'a donc pas grand chose à voir avec ton problème ;)

Citation:

pour l'instant dans notre dépot git on a un répertoire doc/.

C'est toujours utile :D

Citation:

On aimerait placer les sources dans un répertoire src/

J'irais, personnellement, même encore un peu plus loin, en créant un dossier lib, contenant sans doute plusieurs sous dossiers (un pour chaque partie "commune et réutilisable") et un dossier app, qui pourrait aussi contenir un dossier pour chaque programme à générer (pour les applications utilisant les différentes bibliothèques créées dans les sous dossiers de lib)

On pourrait même envisager d'avoir un sous-dossier include (pour les fichiers d'en-tête *.h / *.hpp) et un sous-dossier src (pour les fichiers d'implémentation *.cpp), voire un sous-dossier ui (ou ihm, pour les fichier *.ui générés avec QtDesigner) dans chaque sous-dossiers se trouvant dans lib et app ;)

Citation:

mais on y arrive pas avec Qt Creator,

C'est que vous vous y prenez mal. Mais, sans autre indication de ta part, il sera difficile de dire où tu te vautre ;)

Citation:

de plus on aimerait ajouter des testes pour l'intégration continue

Attention, dans l'idéal, les fichiers qui ne servent qu'aux tests devraient se trouver dans un dossier séparé (disons ... tests, pour la facilité), qui pourrait tout aussi bien respecter la même logique de subdivision (un sous-dossier par bibliothèque testée, éventuellement un dossier include et un dossier src dans chaque sous dossier)

Citation:

mais Qt Creator ne permet que de créer un nouveau projet pour les testes.

Cela nous mène au fond du problème: les fichiers *.pro ne devraient plus être utilisés "à mano" comme c'était le cas il y a vingt ans.

QtCreator supporte parfaitement le gestionnaire de projets appelé CMake, qui présente en plus les facilités

de ne pas dépendre d'un EDI particulier (il est supporté aussi bien par QtCreator que par VisualStudio et plein d'autres), et qui permet même de s'en passer pour les "aficionados" ;)
de ne pas dépendre d'un système d'exploitation quelconque (il peut être utilisé aussi bien sous linux, sous windows ou sous mac)
de ne pas dépendre d'un compilateur particulier
de permettre de créer des projets de tests et de les lancer automatiquement (au travers de ctest)

Vous seriez peut-être bien inspirés de vous intéresser à ce système de gestion et de configuration de projet, cela vous simplifierait énormément la vie ;)

Citation:

On aimerait intégré les testes dans le même répertoire que les sources du projet.

Ce serait une très mauvaise idée, car les tests sont des projets "tout à fait à part", qui resteront -- a priori -- à usage strictement interne de l'équipe de dev.

Citation:

On bloque dessus, on aimerait un truc pro si vous pouviez nous aider ça serait sympa.

Je viens de t'en donner non pas un mais quatre, je dois être vraiment très sympa, du coup :D

Citation:

On veut juste savoir comment organiser nos fichiers de manière pro et ou mettre les testes et comment.

Personnellement, j'organise mes projets de manière toujours à peu près similaires, à savoir
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 -<ROOT> # dossier racine du projet | - apps #les sources pour l'ensemble des programmes | | -prog1 | | | - main.cpp # un des programme | | -prog2 | | | -main.cpp # un autre programme | - docs # tout ce qui a trait à la documentation générée | | - fichier1 | | - fichier2 | - lib # toutes les bibliothèques, les parties "communes et réutilisables" | | - lib1 # une des bibliothèques | | | - include # avec ses fichiers d'en-tête | | | | - header.hpp | | | - src # et ses fichiers d'implémentation | | | | - implementation.cpp | | - lib2 # une autre bibliothèque | | | - include # avec ses fichiers d'en-tête | | | | - header.hpp | | | - src # et ses fichiers d'implémentation | | | | - implementation.cpp | - tests # les différents tests | | - lib1 # on teste une des bibliothèques | | | - include # avec ses fichiers d'en-tête | | | | - header_test.hpp | | | - src # et ses fichiers d'implémentation | | | | - implementation_test.cpp | | - lib2 # on teste une autre bibliothèque | | | - include # avec ses fichiers d'en-tête | | | | - header_test.hpp | | | - src # et ses fichiers d'implémentation | | | | - implementation_tests.cpp
Chaque dossier (hormis les dossier header et src) contiennent un CMakeLists.txt (le fichier utilisé par CMake pour décrire la partie correspondant au dossier en cours).

Ce genre d'organisation permet de garder un nombre "facilement gérable" de fichiers dans les différents dossiers, et de les retrouver "plus facilement" dés que l'on sait quelle à quelle bibliothèque il appartient ;)

NOTA: Chaque dossier que nous trouverons dans les dossiers apps, lib ou tests (typiquement les dossier lib1 et lib2 /prog1 et prog2) correspondront à autant de projets différents, ce qui te permet de travailler plus "précisément" lors du développement.

De plus, cette organisation n'est pas "gravée dans le marbre" et peut parfaitement s'adapter selon les besoins, par exemple, en ajoutant :

un dossier 3rdparty dans lequel tu mettrais les bibliothèques externes qui devront être téléchargées et compilées si elles sont absentes du système
un dossier examples pour présenter quelques exemples rapides de code permettant de présenter l'utilisation de certaines fonctionnalités
un dossier sandboxes qui pourrait contenir des applications "bac à sable" te facilitant le test manuel et le débuggage des fonctionnalités (en développement)
des sous dossier unit_test, integration ou loading qui contiendraient respectivement les tests unitaires, d'intégration et de montée de charge
j'en passe, et sans doute de meilleures ;)

24/01/2022, 11h59
baragouine

Bonjour, si j'ai bien compris je devrais utiliser CMake au lieu de qmake?
24/01/2022, 18h25
koala01

Citation:

Envoyé par baragouine

Bonjour, si j'ai bien compris je devrais utiliser CMake au lieu de qmake?

Cela pourrait être pas mal, en effet, car cela te permettra de t'affranchir des spécificités propres à un EDI (environnement de développement intégré, comme QtCreator) et donc de permettre à ton "équipe de dev" de choisir ses propres outils ;)

De plus, la gestion des projets est finalement bien plus facile avec CMake que selon le format *.pro ;)
25/01/2022, 14h19
baragouine

J'ai restructurer les fichiers et j'ai créer tous les CMakeLists.txt, j'ai un petit problème:
Est-ce que c'est mieux de faire un

Code:

#include "../include/fichier.h"

ou de faire

Code:

#include "fichier.h"

et de configurer le fichier CMakeLists.txt en conséquence avec include_directories(include) ?

Le mieux est d'ajouter le dossier qui contient les fichiers d'en-tête dans la liste des dossiers utilisés à cette fin à l'aide de la fonction include_directories().

Car il faut te dire que, lorsque ton projet prendra de l'ampleur et que tu te retrouveras avec plusieurs bibliothèques séparées, les choses risquent de devenir assez difficile si tu veux utiliser les chemins relatifs.

Pour te donner une vague idée, il m'arrive régulièrement d'avoir deux bibliothèques "à usage général":
une bibliothèque que je nomme généralement tools et qui fournit certains outils d'usage courant
une bibliothèque que je nomme généralement business et qui fournit les fonctionnalités spécifique au domaine sur lequel je travaille

On peut -- déjà -- remarquer le fait que la bibliothèque business va -- très certainement -- avoir certaines dépendances vis à vis de fonctionnalités fournies par tools.

Au delà de ces deux bibliothèques, il m'arrive systématiquement d'avoir un "nombre quelconque" de bibliothèques qui auront toute

soit une dépendance vis-à-vis de tools
soit une dépendance vis-à-vis de business
soit une dépendance vis-a-vis des deux

Alors, tu imagines un peu la galère que cela pourrait représenter d'essayer d'inclure un fichier d'en-tête de ces bibliothèques "de base" avec des chemins relatifs :question:

Cela nous mènerait à du code proche de
Code:

1 2 3 #include <../../tools/include/fichier1.hpp> // parce que je veux inclure un fichier d'en-tête issu de tools #include <../../business/include/fichier2.hpp> // parce que je veux inclure un fichier d'en-tête issu de business
Le tout, sans même compter le fait que l'étape suivante sera de rendre ton projet "aussi modulable que possible".

L'idée générale étant chaque bibliothèque du "projet général" puisse être récupérée dans d'autres projets, sans que l'on ait ** forcément ** envie ni de les compiler une nouvelle fois, ni de les modifier ou de les tester à partir de "ces autres projets".

On pourrait donc se dire que "j'ai créé une bibliothèque de la mort qui tue, je la rend disponible pour d'autres personnes qui en auraient besoin".

Seulement, on ne pourra donc pas se permettre de faire la moindre présomption quant au chemin d'accès aux fichiers d'en-tête.

Et c'est là tout l'intérêt d'utiliser la fonction incude_directories, parce que, à partir du moment où une bibliothèque sera installée (pas forcément dans le dossier d'installation de ton programme), CMake sera en mesure de retrouver le chemin d'accès réel lorsque tu déclarera une dépendance avec cette bibliothèque (au travers de la fonction target_link_libraries)

La réponse est donc, définitivement: utilise les fonctions de CMake qui sont adaptées à ton problème ( include_directories(), target_link_libraries ou autres) et garde ton code source "aussi simple que ces fonctions te le permettent".

NOTA: J'irais même sans doute encore plus loin, en te conseillant d'utiliser de préférence la fonction target_include_directories() qui te permet de déclarer un dossier contenant des fichiers d'en-tête comme étant "public" (susceptible d'être utilisé par les cibles qui dépendent de ton projet) ou comme "privé" (qui ne sera utilisé que de "manière interne", pour la cible en cours de compilation, et indisponibles pour les cibles qui en dépendraient)

Au passage, il existe un bouquin particulièrement intéressant sur CMake: cmake cookbook, qui fournit une série de "recettes toutes prêtes" (à adapter) répondant à certains besoins récurrents et dont le code source est disponible sur git.

Le tout est malheureusement en anglais, mais cela vaudrait sans doute la peine que tu y jette un œil (n'oublie pas de le récupérer quand même :D) ;)

25/01/2022, 16h23
baragouine

merci