Organisation d'un projet C++

Le
lhommedumatch
Bonjour,
Je travaille sur un projet en C++ sous linux.
Je suis en train de réfléchir à une meilleur organisation de
l'arborescence afin d'utiliser les autotools.

Actuellement voici l'arborescence utilisée:
bin => Tous les binaires
lib => les librairies statiques et dynamiques nécessaires
DEV => le code
DEV/Makefile => 1 seul Makefile pour le projet
dans DEV on trouve par exemple :
SOC/src => sources des classes gérant les sockets
SOC/include => headers des classes sockets
SOC/obj => objets des classes sockets

Comment dois-je réorganiser mon projet. Y a -t-il une règle à suivre?
Certains projets open-source ont une arborescence comme suit:
bin
include
lib
src
Dans src, on trouve les sources des différents packages utilisés:
soc => et dedans les sources, les headers et les objets sont
ensembles.

Je me plonge petit à petit dans la doc des autotools et chaque
répertoire doit posséder un Makefile.am d'où mon envie de réorganis=
er
l'arborescence.

Tout aide sera utile
Merci d'avance
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Michael Doubez
Le #20771961
On 14 déc, 17:14, lhommedumatch
Je travaille sur un projet en C++ sous linux.



Juste pour faire un point et parce que tu as déjà eu la réponse dans
comp.lang.c++, ce n'est pas spécifique à C++ donc OT ici.
Tu aurais peut être plus de réponses dans un groupe plus général.

Celà dit, étant donné le volume de fr.comp.lang.c++, il y a pas de
mal.

Je suis en train de réfléchir à une meilleur organisation de
l'arborescence afin d'utiliser les autotools.

Actuellement voici l'arborescence utilisée:
bin => Tous les binaires
lib => les librairies statiques et dynamiques nécessaires
DEV => le code
DEV/Makefile => 1 seul Makefile pour le projet
dans DEV on trouve par exemple :
SOC/src => sources des classes gérant les sockets
SOC/include => headers des classes sockets
SOC/obj => objets des classes sockets

Comment dois-je réorganiser mon projet. Y a -t-il une règle à suivr e?



Chacun a ses petites manies et ça dépends de la taille du projet.
Personnellement, pour les petits projets, j'utilise une organisation à
la open-source comme tu l'as décrite. Ca permet une décomposition en
modules:

src
+ module1
- file1.cc
- private_header.h
+ module2
include
+ module1
- file1.h
+ module2
test

Je vois tout de suite ce qui est exporté d'un module et le paramètre
d'include est juste -I$(PROJECT_PATH)/include.

Je fais en général correspondre mes modules avec les namespaces.

Pour les plus gros projet, je fais des lib dont chacune a la structure
du petit projet

[snip]

Je me plonge petit à petit dans la doc des autotools et chaque
répertoire doit posséder un Makefile.am d'où mon envie de
réorganiser l'arborescence.



C'est dommage qu'un outil ait autant d'impact.

--
Michael
lhommedumatch
Le #20776731
On 15 déc, 10:03, Michael Doubez
On 14 déc, 17:14, lhommedumatch
> Je travaille sur un projet en C++ sous linux.

Juste pour faire un point et parce que tu as déjà eu la réponse dan s
comp.lang.c++, ce n'est pas spécifique à C++ donc OT ici.
Tu aurais peut être plus de réponses dans un groupe plus général.

Celà dit, étant donné le volume de fr.comp.lang.c++, il y a pas de
mal.

> Je suis en train de réfléchir à une meilleur organisation de
> l'arborescence afin d'utiliser les autotools.

> Actuellement voici l'arborescence utilisée:
> bin => Tous les binaires
> lib => les librairies statiques et dynamiques nécessaires
> DEV => le code
> DEV/Makefile => 1 seul Makefile pour le projet
> dans DEV on trouve par exemple :
> SOC/src => sources des classes gérant les sockets
> SOC/include => headers des classes sockets
> SOC/obj => objets des classes sockets

> Comment dois-je réorganiser mon projet. Y a -t-il une règle à sui vre?

Chacun a ses petites manies et ça dépends de la taille du projet.
Personnellement, pour les petits projets, j'utilise une organisation à
la open-source comme tu l'as décrite. Ca permet une décomposition en
modules:

src
  + module1
     - file1.cc
     - private_header.h
  + module2
include
  + module1
     - file1.h
  + module2
test

Je vois tout de suite ce qui est exporté d'un module et le paramètre
d'include est juste -I$(PROJECT_PATH)/include.

Je fais en général correspondre mes modules avec les namespaces.

Pour les plus gros projet, je fais des lib dont chacune a la structure
du petit projet

[snip]

> Je me plonge petit à petit dans la doc des autotools et chaque
> répertoire doit posséder un Makefile.am d'où mon envie de
> réorganiser l'arborescence.

C'est dommage qu'un outil ait autant d'impact.

--
Michael



Merci
La réorganisation va me permettre également de définir des modules
commun pour chaque client
Mais j'ai effectivement commencé à partir sur une arborescence de type
src
+module1
file.cc
file.h
etc

je pense également retirer certaines classes (sockets, thread) qui
pourront être reprise à partir de boost

J'hésite toutefois à partir sur autotools (en m'aidant d'anjuta) ou à
partir sur cmake.
Michael Doubez
Le #20778511
On 15 déc, 22:15, lhommedumatch
On 15 déc, 10:03, Michael Doubez > On 14 déc, 17:14, lhommedumatch
> > Je travaille sur un projet en C++ sous linux.


[snip]
> > Je suis en train de réfléchir à une meilleur organisation de
> > l'arborescence afin d'utiliser les autotools.


[snip]
> Chacun a ses petites manies et ça dépends de la taille du projet.
> Personnellement, pour les petits projets, j'utilise une organisation à
> la open-source comme tu l'as décrite. Ca permet une décomposition e n
> modules:


[snip]
La réorganisation va me permettre également de définir des modules
commun pour chaque client
Mais j'ai effectivement commencé à partir sur une arborescence de typ e
src
+module1
   file.cc
   file.h
etc

je pense également retirer certaines classes (sockets, thread) qui
pourront être reprise à partir de boost



Il y a aussi une lib moins connue mais interessante pour les
applications réseaux/SGBD/XML c'est POCO (aussi sous BOOST software
license).
http://pocoproject.org/

> J'hésite toutefois à partir sur autotools (en m'aidant d'anjuta) ou
à
partir sur cmake.



Mon avis est que ça ne change pas grand chose: c'est vrai que cmake
est plus simple mais il dépends de l'installation chez le client alors
que autotools, une fois généré, ne dépends que d'outils classique. Le
problème d'autotools est que si l'utilisateur veut regénérer le
configure, il a interêt à avoir la même version que toi sinon c'est
une galère.

--
Michael
Publicité
Poster une réponse
Anonyme