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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
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
On 14 déc, 17:14, lhommedumatch <ludocl...@yahoo.com> 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.
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
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.
On 15 déc, 10:03, Michael Doubez <michael.dou...@free.fr> wrote:
On 14 déc, 17:14, lhommedumatch <ludocl...@yahoo.com> 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.
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
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
On 15 déc, 22:15, lhommedumatch <ludocl...@yahoo.com> wrote:
On 15 déc, 10:03, Michael Doubez <michael.dou...@free.fr> wrote:
> On 14 déc, 17:14, lhommedumatch <ludocl...@yahoo.com> 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.
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.