Journal Sources et arborescence des fichiers

Posté par  .
Étiquettes : aucune
0
4
juin
2004
Vu que mon code commence à prendre un peu d'ampleur, je me demandais s'il y avait des habitudes/standards en ce qui concerne l'organisation des fichiers de code. Je ne parle pas du contenu, mais des répertoires, du nommage, etc.

Par exemple, je croise souvent des projets qui mettent tous les fichiers .cc et .h dans le même répertoire src. D'autres qui découpent plus ou moins logiquement en sous-répertoires...

Les répertoires de plusieurs dizaines de fichiers me semblent touffus et peu parlants, en revanche, 4 ou 5 fichiers, ça fait un peu vide...

Je suis preneur de conseils, pointeurs, lectures à ce sujet sachant que depuis que j'ai dompté Kdevelop, j'arrive à me débrouiller avec les sous-répertoires et les autoconf/automake.

  • # répertoires

    Posté par  (site web personnel) . Évalué à 4.

    Souvent, on sépare les .h et les .cc, en un répertoire src/ et un répertoire include/. En fait, je le fais souvent plus ou moins machinalement, mais ce n'est pas forcément une bonne idée.

    Par contre, faire un sous répertoire par "module" de ton projet, c'est clairement une bonne chose. Ce qui est intéressant, c'est de repérer suffisament bien les dépendances de chaque répertoire, et ensuite, de ne donner que les chemins d'include (là ou le compilo va chercher les .h) nécessaires dans chaque sous répertoire pour te forcer à les respecter. Le résultat, c'est que tu évites de faire un projet "plat de nouilles", tu as du code réutilisable. Si tu veux réutiliser un module dans un autre projet, tu récupère ce sous répertoire et ses dépendances, et hop !

    La couche d'après, c'est de compiler chaque sous répertoire en une bibliothèque (en général statique), d'avoir un beau système de Makefiles récursifs, et tu gagneras en performances à l'édition de liens.

    Un autre avantage du système, c'est que ton gestionnaire de versions te permet surement de travailler sur un seul répertoire à la fois (CVS, subversion, arch si tu utilise des configurations). Sur un gros projet, ça évite de reparcourire tout l'arbre des sources à la moindre opération, c'est plutôt appréciable !

    • [^] # Re: répertoires

      Posté par  . Évalué à 2.

      Effectivement pour le include/ j'ai vu ça. Je trouve pas ça très "organisé", sauf dans le cas où les .h pourraient servir d'interfaces entre les modules, ou des plugins. J'ai plutôt tendance à laisser les .h avec les .cc correspondants, je trouve ça plus cohérent, mais je me retrouve à faire des #include "rep/ss-rep/ss-ss-rep/header.h" dans certains sources, et c'est assez lourd.

      Dans ce cas, on voit tout de suite où est le header, mais si on sépare les modules, et qu'il y a des includes croisés, c'est aussi la merde à la compilation, et là, un include/ commun serait avantageux...

      Je me demande si ça serait pas plus propre d'avoir les .h à la fois dans les répertoires des .cc et dans le include/.

      • [^] # Re: répertoires

        Posté par  (site web personnel) . Évalué à 3.

        > mais si on sépare les modules, et qu'il y a des includes croisés,

        Justement, l'intérêt de séparer tes modules, c'est de mettre en évidence les includes croisés, et de les éviter.

        Exemple : Les dévelopeurs de Gimp ont développé leur propre toolkit, qui est devenu par la suite Gtk. si il y avait eu des dépendances croisées Gtk <-> The Gimp, et bien tous les programmes Gtk se seraient retrouvés avec des dépendances dans Gtk :-(

        Pour les includes à ralonge, tu peux aussi faire juste #include "fichier.h" et compiler avec gcc -I rep/ss-rep/ss-ss-rep, c'est une question de gout ... L'intérêt de l'include à ralongue, c'est que ça te donne une sorte d'espace de noms sur tes fichiers. Tu peux avoir un fichier config.h dans chaque répertoire sans qu'il n'y ai de clash de nom.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.