Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Organisation d'un projet C++

3 réponses
Avatar
lhommedumatch
Bonjour,
Je travaille sur un projet en C++ sous linux.
Je suis en train de r=E9fl=E9chir =E0 une meilleur organisation de
l'arborescence afin d'utiliser les autotools.

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

Comment dois-je r=E9organiser mon projet. Y a -t-il une r=E8gle =E0 suivre?
Certains projets open-source ont une arborescence comme suit:
bin
include
lib
src
Dans src, on trouve les sources des diff=E9rents packages utilis=E9s:
soc =3D> et dedans les sources, les headers et les objets sont
ensembles.

Je me plonge petit =E0 petit dans la doc des autotools et chaque
r=E9pertoire doit poss=E9der un Makefile.am d'o=F9 mon envie de r=E9organis=
er
l'arborescence.

Tout aide sera utile
Merci d'avance

3 réponses

Avatar
Michael Doubez
On 14 déc, 17:14, lhommedumatch wrote:
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
Avatar
lhommedumatch
On 15 déc, 10:03, Michael Doubez wrote:
On 14 déc, 17:14, lhommedumatch wrote:

> 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.
Avatar
Michael Doubez
On 15 déc, 22:15, lhommedumatch wrote:
On 15 déc, 10:03, Michael Doubez wrote:
> On 14 déc, 17:14, lhommedumatch wrote:

> > 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