Discussion :

[benjamin0]

Bonjour,

Supposant le code source d'une librairie réparti comme suit
nom_du_module/A/a1.{h,cpp}
nom_du_module/A/a2.{h,cpp}
nom_du_module/B/b1.{h,cpp}
nom_du_module/B/b2.{h,cpp}
(il y a d'autres librairies dans le même projet, considérées indépendantes),

préférez-vous écrire à partir d'un fichier .cpp

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
#include "nom_du_module/A/a1.h"
#include "nom_du_module/B/b2.h"
...

(comme ici ou là), ou bien

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
#include "a1.h"
#include "b2.h"
...

(avec les directives -I/.../nom_du_module/{A,B}) ...Et pourquoi ?

J'apprécie la première forme car elle supprime tout risque de collision ("Util.h" par exemple est présent dans plusieurs des librairies), et permet de voir clairement ce qui est inclus. En revanche à chaque changement de répertoire il faut aussi modifier tous les #include correspondants. La seconde forme n'a pas ce dernier défaut, mais n'a pas non plus les qualités de l'autre approche.

Y a-t-il une manière standard de procéder ?

Merci d'avance.

[Ehonn]

Bonjour et bienvenue

Chaque projet un tantinet sérieux qui propose une bibliothèque devrait avoir un "make install" ou équivalent.
À partir de là, la "bonne façon" est de faire un #include <lib/fct.hpp> (fichier d'entête dans un des répertoires standards) et de rajouter un flag -lnom_de_la_lib à l'éditeur de lien.

Si l'utilisateur choisit de ne pas installer la bibliothèque dans un répertoire prévu à cet effet. Il devra rajouter le flag -I/chemin/vers/include/ au compilateur et -L/chemin/vers/lib/ à l'éditeur de lien.

(Ces paramètres sont configurables dans les menus des IDE.)

[benjamin0]

Merci, mais je vois que je n'ai probablement pas été très clair ^^

Le "make install" d'une librairie ajoute en général des headers dans, par exemple, /usr/include/. Est-ce une bonne pratique de reproduire la structure du code source, et donc d'avoir /usr/include/nom_du_module/dossier1/dossier2/fichier.h ...etc, ou de tout "mettre à plat" et se retrouver avec /usr/include/nom_du_module/fichier.h ?

Par souci de cohérence, dans le code source de la librairie on ferait #include "nom_du_module/dossier1/dossier2/fichier.h" dans le premier cas, et #include "fichier.h" dans le second. Je préfère le premier style, mais me demande s'il y a une raison générale de préférer l'un ou l'autre.

[Ehonn]

#include "" cherche dans les fichiers d'entête locaux et ceux du système.
#include <> cherche dans les fichiers d'entête du système.
(C'est un peu plus subtile que ça : Différence entre #include <> et #include " " (mais cette règle simplifiée devrait suffire))

Par défaut sur Debian GNU/Linux, il y a au moins les répertoires /usr/include et /usr/local/include qui sont considérés comme appartenant au système. Par convention /usr/ appartient à la distribution, /usr/local/ est le répertoire d'installation pour l'administrateur.

À partir de là, le projet installe :
- les fichiers d'entête dans /usr/local/include.
- les bibliothèques dans /usr/local/lib.
- etc pour bin share ...
Pour les fichiers d'entête, on aura donc /usr/local/include/lib/lib.hpp /usr/local/include/lib/lib.hpp /usr/local/include/lib/container.hpp /usr/local/include/lib/algo.hpp /usr/local/include/lib/benchmark.hpp /usr/local/include/lib/....

De ce fait l'utilisateur de la bibliothèque, utilise ceci dans son code :
#include <lib/lib.hpp>.
(et devra linker avec -lnom_de_la_lib)

Si la bibliothèque se retrouve un jour dans les dépôts de la distribution, le code utilisateur et la façon de compiler ne changeront pas

--- --- ---

Le "make install" d'une librairie ajoute en général des headers dans, par exemple, /usr/include/. Est-ce une bonne pratique de reproduire la structure du code source, et donc d'avoir /usr/include/nom_du_module/dossier1/dossier2/fichier.h ...etc, ou de tout "mettre à plat" et se retrouver avec /usr/include/nom_du_module/fichier.h ?

Non, car le code ne sera pas portable (en plus d'être non-esthétique).
Les répertoires d'include par défaut servent à résoudre ce souci. On peut ajouter un répertoire à la liste des répertoires d'include à utiliser avec -Ichemin/vers/include

Par souci de cohérence, dans le code source de la librairie on ferait #include "nom_du_module/dossier1/dossier2/fichier.h" dans le premier cas, et #include "fichier.h" dans le second. Je préfère le premier style, mais me demande s'il y a une raison générale de préférer l'un ou l'autre.

#include <lib/lib.hpp> par cohérence/logique et pour éviter les conflits et erreurs (que ce soit à l'installation ou à l'utilisation).

[benjamin0]

Merci pour ces rappels de compilation sous Linux, mais je les connais déjà un peu et ce n'était pas ma question

Je re-reformule en partant de ton exemple :

Tu disposes du code source
lib/lib.hpp
lib/Containers/container.hpp
lib/Algos/Type1/algo.hpp
lib/Benchmarks/Case1/benchmark.hpp

Tu l'installes en
/usr/local/include/lib/lib.hpp
/usr/local/include/lib/container.hpp
/usr/local/include/lib/algo.hpp
/usr/local/include/lib/benchmark.hpp

ou en
/usr/local/include/lib/lib.hpp
/usr/local/include/lib/Containers/container.hpp
/usr/local/include/lib/Algos/Type1/algo.hpp
/usr/local/include/lib/Benchmarks/Case1/benchmark.hpp
(suppose que ces chemins aient un sens pour l'utilisateur final)

? Y a-t-il une raison de préférer l'une des deux approches ?

[Ehonn]

En fait ta question n'était pas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
#include "nom_du_module/A/a1.h"
#include "nom_du_module/B/b2.h"

vs

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
#include "a1.h"
#include "b2.h"

mais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
#include "nom_du_module/A/a1.h"
#include "nom_du_module/B/b2.h"

vs

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
#include "nom_du_module/a1.h"
#include "nom_du_module/b2.h"

Je m'en fiche ^^ (du moment que l'on remplace les #include "" par #include <> si c'est installé dans un répertoire standard)
Ça dépend si tu as beaucoup de fichiers d'entête qui peuvent être regroupés dans un même dossier. Si c'est la cas, c'est plus simple pour l'organisation de la bibliothèque (et ça ne change pas grand chose pour l'utilisateur). On peut aussi fournir un fichier d'entête qui porte le nom du dossier et qui permet de factoriser l'ensemble des #include du dossier.

[benjamin0]

En fait ta question n'était pas : [...] vs [...]

mais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
#include "nom_du_module/A/a1.h"
#include "nom_du_module/B/b2.h"

vs

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
#include "nom_du_module/a1.h"
#include "nom_du_module/b2.h"

Non : c'était bien en comparaison avec la première forme, sans le "lib/" (supposant bien sûr un -I/usr/local/include/lib/).
Mais à partir du moment où le code source contient des #include "truc.h" elles sont presque équivalentes.

Bon, ça me fait une première réponse : "on s'en fiche" ^^
Un autre avis ?

[Ehonn]

Du coup j'avais répondu.

#include <lib/lib.hpp> par cohérence/logique et pour éviter les conflits et erreurs (que ce soit à l'installation ou à l'utilisation).

Donc, #include <lib.hpp> est à bannir au profit de #include <lib/lib.hpp>.
(Le seul #include <lib.hpp> que l'on peut tolérer, est celui qui porte le nom de la bibliothèque (sinon, tout mettre dans un dossier).)

[JolyLoic]

Généralement, je distingue 4 cas :
1 - Les .h du même module, que j'inclus par #include "monFichier.h", sans rien mettre dans l'include path
2 - Les .h des bibliothèques tierces, que j'inclus par #include <boost/mpl.h>, avec l'include path modifié pour que ça marche bien.
3 - Les .h des autres modules du projet, que j'inclus par #include "projet/module/header.h".
4 - Cas particulier, sur lequel je ne suis pas encore fixé : Les fichiers de test unitaire d'une biblitohèque, que je mets en sous-répertoire de cette bibliothèque, #include "../FichierATester.h".

Pourquoi ? Parce que les systèmes de build sont toujours compliqués, j'ai donc envie de les simplifier au possible, et que le code compile autant que possible avec une config par défaut. Le 1 et le 4 parce que c'est ce qu'il y a de plus simple, rien à ajouter, ça résiste au déplacement. Le 3 me permet de n'avoir à ajouter qu'un seul chemin pour tout mon code. Le 2 m'est nécessaire car d'une machine à l'autre, on ne peut pas toujours garantir l'emplacement (ou la version) des bibliothèques externes.

Alors certes, si on réorganise son code, le 3 me forcera à modifier tous les clients. Mais comme le chemin est explicitement présent, un simple grep permet de le faire sans risque (contrairement par exemple à des #include "../header.h").

[benjamin0]

Et bien ça ne s'est pas trop bousculé Mais c'est sans doute une question trop subjective. Merci à vous deux ! Au final je fais pareil pour les points 2 et 3, mais préfère pour l'instant placer les tests unitaires dans un répertoire à part (reproduisant l'arborescence du code source), et indiquer le chemin complet même pour le module en cours. Je verrai au fil du temps.