IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

Quelle arborescence de fichiers utiliser pour nos dépôts ? [Débat]


Sujet :

C++

  1. #1
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut Quelle arborescence de fichiers utiliser pour nos dépôts ?
    Quelle arborescence de fichiers utiliser pour nos dépôts ?
    Venez décrire votre organisation et en débattre !

    Lorsqu'on travaille sur un projet, respecter les bons principes de la programmation et ajouter des commentaires pour pouvoir générer une documentation n'est pas suffisant.

    En effet, pensez à la personne qui essayera de relire vos dizaines voire centaines de fichiers. Il faut qu'elle puisse trouver le plus rapidement les informations/fichiers qu'elle cherche.

    J'ai souvent vu des projets avec à la racine :
    - un dossier bin pour les exécutables ;
    - un dossier lib pour les dépendances ;
    - un dossier include pour les fichiers d'en-têtes de la bibliothèque ;
    - un dossier src pour les sources (.cpp et .h) ;
    - un dossier doc pour la documentation ;
    - un fichier Makefile/CMake/de projet pour compiler ;
    - un README ;
    - un fichier INSTALL décrivant la procédure d’installation ;
    - un dossier datafile/ressources pour tous les fichiers sons/images.

    Mais quand on se penche sur le contenu de ces dossiers et des fichiers, chacun fait un peu à sa sauce.
    On peut se retrouver avec 50 fichiers dans un seul dossier dans les sources ou à l'inverse avoir 7 fichiers pour 4 dossiers.



    D'après vous,
    Comment devrait être constituée l'arborescence d'un projet ?
    Que mettre dans les fichiers README et INSTALL ? Quel « plan » adopter, quel « pattern » suivre pour ces fichiers ?
    Pour les fichiers sources, faut-il créer un dossier par namespace ?
    Comment regrouper/trier les fichiers sources ? Combien faut-il mettre de fichiers « maximum » dans un dossier ?
    Quelle profondeur donner à notre arborescence ?

    Bref, quel est pour vous le squelette type d'une arborescence idéale de fichiers et quelles seraient vos consignes pour le remplir ?
    Images attachées Images attachées  

  2. #2
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Salut,

    Lorsque je crées un projet qui est destiné à être compilé par plusieurs systèmes ( autotools, code::blocks et cmake, pour ne citer qu'eux), j'ai tendance à créer un dossier par catégorie.

    Pour ce qui est de la documentation, je rajoute (parce que je l'utilise ) souvent un dossier "doxygen" qui contiendra la configuration (doxyfile, par défaut ) et les éventuelles pages connexes ("group.dox", "namespace.dox" et autres joyeusetés qui permettent de créer des pages en relation avec un concept en général mais non relative à une classe particulière), le tout en faisant en sorte que la documentation générée se trouve dans le dossier doc.

    Je place d'office tous mes fichiers d'en-tête dans le dossier include, mais je le subdivise régulièrement en fonction de "modules" particuliers.

    De la même manière, je mets tous mes fichier d'implémentation, à l'exception des fichiers relatifs au tests unitaire, dans le dossier src, subdivisé par espace de noms ou par "module".

    Ceci dit, j'essaye généralement que la compilation ne se fasse pas dans le même dossier, afin d'éviter que le gestionnaire de version concurrente n'en vienne à essayer de commiter des choses qui n'ont pas lieu d'être (comme les fichiers objets par exemple).

    au final, l'arborescence ressemble à quelque chose comme
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    <root_directory>
        |-> autotool (toutes les joyeusetés prorpres au outils autocof, autoheader, et automake)
        |    |-> src (les joyeusetés propres à la compilation des sources, en 
                      respectant l'aborescence du dossier contenant les fichier d'implémentation)
        |    |-> tests (et celles pour les tests unitaires)
        |-> codeblocks (les fichiers propes aux projet code::blocks)
        |-> cmake (et ceux propres au système CMake)
        |-> doc (gentillement rempli par doxygen)
        |-> doxygen (j'en ai parlé plus haut)
        |-> include
        |    |-> module1
        |    |-> module2
        |-> src
        |    |-> module1
        |    |-> module2
        |-> test 
        |    |-> module1
        |    |-> module2
    Quant aux bibliothèques externes, elles sont installées dans des dossiers clairement séparés (boost dans un dossier qui lui est propre, et Qt dans un autre), à part quelques unes (libiconv, icu ou libxml2) qui sont directement dans le dossier de mon compilateur.

    J'utilise des variables d'environnement pour maintenir tout cela en place, comme
    • QTDIR qui est le dossier racine dans lequel se trouve Qt
    • QTBIN qui est le dossier dans lequel se trouvent les exécutables et les dll de Qt (définie sous windows comme étant égale à %QTDIR%\qtbase\bin et sous linux comme étant égale à ${QTDIR}/qtbase/bin)
    • BOOSTDIR qui est le dossier racine de boost
    • BOOST_VERSION qui correspond à une chaine de caractères représentant la version de boost (actuellement 1_54)
    • BOOST_HEADERS qui indique le dossier dans lequel se trouvent les en-tête de boost (définie, sous windows comme étant égale à %BOOSTDIR%\include\boost-%BOOST_VERSION% , sous linux comme étant égale à ${BOOSTDIR}/include/boost-${BOOST_VERSION} et
    • BOOST_LIB (définie sous windows comme étant égale à %BOOSTDIR%\lib et sous linux comme étant égale à ${BOOSTDIR}/lib )
    De cette manière, je peux passer d'une version à l'autre rien qu'en changeant la valeur de QTDIR ou de BOOST_VERSION, et je peux les utiliser dans les différents scripts / EDI pour la configuration

    Note que je dispose de scripts pour définir ces variables sans devoir toucher au variables d'environnement au niveau du panneau de configuration

    Enfin, je n'ai aucun a priori quant au nombre (minimal ou maximal) de fichiers qu'un dossier peut / doit contenir.

    Je structure mon arborescence en fonction des modules que je crées et chaque dossier contient donc les fichiers nécessaires et utiles au module en question

    S'il y en a un qui contient 7 fichiers et l'autre qui en contient 150, c'est qu'un module est beaucoup plus complexe que l'autre, tout simplement
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    301
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 301
    Points : 345
    Points
    345
    Par défaut
    Chez moi ça ressemblait pas mal à ce que viens d'exposer koala01. J'ai cependant récemment changé mon organisation pour privilégier un dossier par module (un module étant une entité compilée à part généralement sous forme de lib statique ou dynamique) :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    <root_directory>
        |-> module1
        |    |-> module1 (include)
        |    |-> src
        |    |-> test
        |-> module2
        |    |-> module2 (include)
        |    |-> src
        |    |-> test
    J'utilise également des sous-répertoires "detail" (dans les includes ou les sources) à la manière de boost.
    Je trouve le découpage par module plus "propre" si tes modules sont très indépendants (ça permet notamment de partager plus facilement un module, de le versionner à part, ...)
    Après (honte à moi) je n'ai pas de répertoire doc, doxygen et autres, mais pour respecter l'idée, je devrais sans doute en avoir un dans chaque module.

  4. #4
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut
    Bonjour,

    Que mets-tu dans tes dossiers "détails" ?
    Je présume que tu mets dedans toutes les classes/fonctions qui ne se retrouvent pas "exposées" dans l'interface de ta bibliothèque ?

  5. #5
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 113
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 113
    Points : 32 958
    Points
    32 958
    Billets dans le blog
    4
    Par défaut
    Bonjour,

    en général je suis plus ou moins toujours le même schéma:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    - root
    -- Docs
    -- Exe
    -- Dev
    --- Src
    --- Externals
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  6. #6
    Membre averti
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    301
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 301
    Points : 345
    Points
    345
    Par défaut
    @Neckara : oui c'est bien ça: tout ce qui est nécessaire pour que le module puisse fonctionner mais qui n'est pas utile pour l'utilisateur du module (hors interface donc du dit module)

  7. #7
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par CedricMocquillon Voir le message
    Chez moi ça ressemblait pas mal à ce que viens d'exposer koala01. J'ai cependant récemment changé mon organisation pour privilégier un dossier par module (un module étant une entité compilée à part généralement sous forme de lib statique ou dynamique) :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    <root_directory>
        |-> module1
        |    |-> module1 (include)
        |    |-> src
        |    |-> test
        |-> module2
        |    |-> module2 (include)
        |    |-> src
        |    |-> test
    J'utilise également des sous-répertoires "detail" (dans les includes ou les sources) à la manière de boost.
    Je trouve le découpage par module plus "propre" si tes modules sont très indépendants (ça permet notamment de partager plus facilement un module, de le versionner à part, ...)
    En effet, cela permet de garder très certainement une hiérarchie plus "propre" et, à bien y réfléchir, je vais très certainement "migrer" vers ce type d'organisation
    Après (honte à moi) je n'ai pas de répertoire doc, doxygen et autres, mais pour respecter l'idée, je devrais sans doute en avoir un dans chaque module.
    Et encore, cela dépend fortement : rien ne t'interdit effectivement d'avoir un dossier doxygen (pour ne citer que lui) dans chaque module, pour tout ce qui a trait au module en question, mais qu'est ce qui t'interdit d'avoir un dossier doxygen également dans le dossier racine de ton application / projet, pour tout ce qui est relatif au projet en général et pas forcément à un module particulier

    L'avantage en générant la documentation sur le dossier racine, c'est que tu obtiens directement la doc de tous les modules, sans devoir commencer à ouvrir un onglet par module (à cause des interdépendances) et que cela te permet, justement, d'avoir une vision plus globale de ces dépendances

    Et, même si tu décides de placer le contenu de tous tes modules dans l'espace de noms global (c'est un choix que je ne cautionne pas, mais bon, certains le font ), tu peux avantageusement utiliser la notion de groupe ( @group pour en définir un, @ingroup pour indiquer qu'une classe ou une fonction fait partie du groupe en question) pour que la documentation se répartisse dans les différents modules (d'ailleurs, il semble cohérent d'utiliser la notion de groupe même si tu utilises des espaces de noms différents en fonction de tes modules )
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  8. #8
    Membre expert

    Avatar de germinolegrand
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Octobre 2010
    Messages
    738
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : Octobre 2010
    Messages : 738
    Points : 3 892
    Points
    3 892
    Par défaut
    Pour ma part, ça a tendance à ressembler à ça pour les projets sérieux :
    (en + les éléments versionnés, en - les éléments ignorés dans le dépôt)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
     
    +depot
    |+.bzrignore
    |+executive (répertoire d'exécution, réplique de l'environnement client)
    |+projects
    ||+Projet.cbp
    ||-bin (contient les binaires)
    |||-BuildTarget1
    |||-BuildTarget2
    ||-obj (contient les temporaires nécessaires durant le build)
    |||-BuildTarget1
    |||-BuildTarget2
    |+Projet1 (ici une application)
    ||+dossier
    ||+fichier.cpp
    ||+fichier.h
    |+Projet2 (ici une lib)
    ||-bin (contient les .dll)
    ||-lib (contient les .a)
    ||+dossier
    ||+fichier.cpp
    ||+fichier.h
    |+Projet3
    |+codecommun1
    |+codecommun2

  9. #9
    Expert éminent

    Avatar de deusyss
    Homme Profil pro
    Expert Python
    Inscrit en
    Mars 2010
    Messages
    1 659
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Expert Python
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2010
    Messages : 1 659
    Points : 8 442
    Points
    8 442
    Par défaut
    Personnellement, jusqu'à il y a peu, je m'adaptais à mes développements, me focalisant surtout sur une structure bien ordrée et rangée.

    Récemment, ayant cherché à créer un exécutable windows à partir de code source PYTHON, les outils m'ont imposés d'eux mêmes une certaine structure. Maintenant, donc, mes projets sont plutôt organisé avec cette structure:
    <DOSS PJ>
    ----<fichiers sources *.py>
    ----<fichier icone>
    ----<packages>
    ----<Dossiers doc>
    ----<Dossier bdd>
    ----<Dossier img>
    ----<Autre dossier data>
    ----<Dossier pour la creation de l'exe>
    --------Fichier de licence
    --------Fichier texte pre install
    --------Fichier texte post install

    J'integre le contenu de readme dans la documentation. Pour le reste, je met à dispo code source, paquet .deb, zip windows standalone et un exe d'install windows. Je me passe donc de fichier INSTALL.txt

    EDIT: A titre personnel, je pense que la structure retenue et utilisée importe peu, du moment que celle-ci utilise une certaine logique et reste cohérente
    "La connaissance appartient à tout le monde" (Film Antitrust)

    Tout le nécessaire pour Python:
    *News/Accueil *Cours/tutoriels *FAQ
    *Forums *Outils dédiés *Mon espace personnel avec mes Articles, Cours et Tutoriels

  10. #10
    r0d
    r0d est déconnecté
    Expert éminent

    Homme Profil pro
    tech lead c++ linux
    Inscrit en
    Août 2004
    Messages
    4 262
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : tech lead c++ linux

    Informations forums :
    Inscription : Août 2004
    Messages : 4 262
    Points : 6 680
    Points
    6 680
    Billets dans le blog
    2
    Par défaut
    pour moi, ça dépend du type de projet. Par exemple, si je fais une lib (donc destinée à être utilisée par d'autres), je sépare bien les en-têtes des sources, sinon je préfère autant regrouper les fichiers par classe (en-tête et source d'une même classe dans le même dossier). Pour les programmes qui requièrent des ressources (images, vidéos, sons, ...), je crée un fichier ressource à la racine. En gros, ça ressemblera à ça:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
     
    +trunk
    -- bin // les binaires qui sont générés
        |-- win64
              |-debug
              |-release
        |-- win32
              |-debug
              |-release
        |-- linux64
              |-debug
              |-release
        |-- linux32
              |-debug
              |-release
    -- ext // code externe
        |-- bin // les binaires compilés
              |-- win64
                  |-debug
                  |-release
              |-- win32
                  |-debug
                  |-release
              |-- linux64
                  |-debug
                  |-release
              |-- linux32
                  |-debug
                  |-release
        |-- libs // ici je met les libs telles que je les ai récupéré, avec la doc, le code source, etc. j'aime bien les mettre dans le dépôt, mais ce n'est pas systématique
              |-- boost
              |-- sfml
    -- ressources // images, videos, sons, fichier de config, etc.
    -- projects
        | -- visual
        | -- codeblocks
        | -- cmake
    -- src
        | -- model
        | -- view
        | -- controller
        | -- common
    -- temp // ici tous les fichiers temporaires (objets, etc.), ce répertoire n'est présent qu'en local (pas sur le dépôt)
    -- doc
    « L'effort par lequel toute chose tend à persévérer dans son être n'est rien de plus que l'essence actuelle de cette chose. »
    Spinoza — Éthique III, Proposition VII

  11. #11
    Rédacteur
    Avatar de imikado
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2006
    Messages
    5 239
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Finance

    Informations forums :
    Inscription : Décembre 2006
    Messages : 5 239
    Points : 19 100
    Points
    19 100
    Billets dans le blog
    17
    Par défaut
    On peut répondre pour les projets web, ou c'est réservé aux langages compilés ?
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  12. #12
    Membre éprouvé

    Profil pro
    Inscrit en
    Décembre 2008
    Messages
    533
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2008
    Messages : 533
    Points : 1 086
    Points
    1 086
    Par défaut
    Vous commitez vos binaires, vous ?

  13. #13
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut
    Citation Envoyé par imikado Voir le message
    On peut répondre pour les projets web, ou c'est réservé aux langages compilés ?
    Un projet web n'est pas forcément un projet basé sur des langages uniquement interprétés
    Mais oui, tu peux présenter ton arborescence.

    Citation Envoyé par cob59 Voir le message
    Vous commitez vos binaires, vous ?
    Personnellement, je dirais non.
    Le dossier "bin" est souvent vide et n'est remplit que par l'utilisateur lorsqu'il souhaite compiler les sources.
    Mais j'ai déjà vu des projets qui commitaient bien les binaires.

  14. #14
    Membre éclairé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2010
    Messages
    434
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Janvier 2010
    Messages : 434
    Points : 654
    Points
    654
    Par défaut
    A ça j'ajouterais une branche pour chaque version de livraison

  15. #15
    Rédacteur
    Avatar de imikado
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2006
    Messages
    5 239
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Finance

    Informations forums :
    Inscription : Décembre 2006
    Messages : 5 239
    Points : 19 100
    Points
    19 100
    Billets dans le blog
    17
    Par défaut
    Oui je sais, mais merci pour la réponse, personnellement, utilsant un framework, il me génère l'arborescence suivante:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
     
    + MonProjet
    |-conf
    |-data
      |--img
      |--log
      |--upload
    |-layout
    |-model
    |-module
      |--monModule
        |---view
    |-plugin
    |-plubic
      |--css
        |---images
      |--js
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  16. #16
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 113
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 113
    Points : 32 958
    Points
    32 958
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par cob59 Voir le message
    Vous commitez vos binaires, vous ?
    Oui, il y a toujours un binaire/executable release fonctionnel qui est dans le repo.
    Il n'y a pas que des développeurs dans une équipe.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  17. #17
    Membre expert

    Avatar de germinolegrand
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Octobre 2010
    Messages
    738
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : Octobre 2010
    Messages : 738
    Points : 3 892
    Points
    3 892
    Par défaut
    Pour ce qui est des binaires, de mon côté il y a un dépôt exprès "releases" qui contient des versions des logiciels compilées à l'usage de ceux qui n'ont pas de compilateur dans l'équipe, mais il y a aussi les outils destinés à entretenir l'environnement de développement (dépôt "tools"), ainsi que les .a et .dll dont on n'assure pas la maintenance ou dont le processus de génération est trop complexe pour être faite par tous les devs (exemple la SFML qu'il faut générer depuis un dépôt github, nécessite les outils supplémentaires git et cmake).

  18. #18
    Membre éprouvé

    Profil pro
    Inscrit en
    Décembre 2008
    Messages
    533
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2008
    Messages : 533
    Points : 1 086
    Points
    1 086
    Par défaut
    Citation Envoyé par Bousk Voir le message
    Oui, il y a toujours un binaire/executable release fonctionnel qui est dans le repo.
    Il n'y a pas que des développeurs dans une équipe.
    En général je préfère créer un dossier package/ en haut de l'arborescence, et y livrer régulièrement (pas forcément à chaque commit) des archives ou installateurs prêts à l'emploi, qui contiennent les bin/lib/data requis. Dans mon cas, via l'utilisation de CPack.

    C'est aussi simple pour les non-dev qui ont juste à télécharger 1 setup/.zip et ça évite de commiter systématiquement des binaires volumineux, longs à uploader et pas forcément stables/livrables.

  19. #19
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    Décembre 2010
    Messages
    49
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations forums :
    Inscription : Décembre 2010
    Messages : 49
    Points : 20
    Points
    20
    Par défaut
    Ça dépend des projets, bien évidemment. Pour la plupart de mes projets en C/C++, je suis ce schéma :

    build
    bin (si généré(s))
    lib (si générée(s))
    *.o
    Makefile
    include
    samples
    src
    tests
    COPYING
    README.md
    CHANGELOG
    .git

    Et je fais de la compilation out-of-src-tree. Sur de gros projets, je remplace simplement le Makefile par un CMakeFile.

    Pour mes projets en Haskell, je suis la recommandation de cabal et m’y tiens.

  20. #20
    Membre émérite
    Inscrit en
    Janvier 2006
    Messages
    718
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 718
    Points : 2 711
    Points
    2 711
    Par défaut
    Citation Envoyé par cob59 Voir le message
    Vous commitez vos binaires, vous ?
    En aucun cas!
    Une règle qui me semble fondamentale dans un gestionnaire de versions est de ne jamais valider (traduction du mot commit) ce qui est créé par des outils (compilateur, langage de formatage, ou autre) : on doit pouvoir relancer les outils et reconstituer les fichiers.

    Si vous le faites :
    - vous n'êtes pas certain que le fichier généré est synchro avec les sources (il peut avoir été compilé avant vos dernières modifs), parfois on voudrait que ce soit le cas, parfois non (genre mettre dans le dépôt la dernière version de prod...)
    - à chaque fois que vous relancez toute la chaîne de compilation, vous allez recréer ces fichiers et vous prenez le risque qu'ils soient absorbés quand vous lancez le commit
    (exemple vécu avec un projet libre dont je ne suis pas l'auteur mais auquel je collabore : un fichier html est généré à chaque fois avec des numéros de version dedans; à chaque commit le VCS le voit comme un fichier modifié, et une fois sur 2 j'ai un conflit avec le même fichier "modifié" par un collègue...)
    D'autant plus qu'un diff entre binaires est toujours moins bon que pour des fichiers textes (il n'existe pas d'algorithme "merge" capable de fonctionner sur n'importe quel format binaire, alors que pour le texte divisé en ligne ça existe).

    Donc, d'accord pour un répertoire "bin" à la racine, mais dans le gestionnaire de versions, il doit être vide (ou se limiter à des .ignore ou ce genre de choses).
    D'ailleurs je trouve que c'est également valable pour un répertoire lib/ contenant les dépendances : avec Ant ou Maven (Java) on a prévu des dépôts spécifiques pour les dépendances, je ne vois pas pourquoi on ne ferait pas de même dans d'autres langages.

    Citation Envoyé par Bousk
    Oui, il y a toujours un binaire/executable release fonctionnel qui est dans le repo.
    Il n'y a pas que des développeurs dans une équipe.
    En général les non-développeurs ne vont pas chercher dans Git ou Subversion. Ceux qui veulent les binaires n'ont rien à faire des sources, et inversement, c'est pour ça qu'on n'utilise pas les mêmes outils pour les deux dépôts (pour les dépôts de binaires, le plus souvent un simple FTP suffit)

Discussions similaires

  1. Réponses: 1
    Dernier message: 23/02/2015, 12h16
  2. Réponses: 18
    Dernier message: 11/05/2007, 20h35
  3. Réponses: 3
    Dernier message: 05/12/2006, 02h08
  4. Quel format de fichier utiliser pour les maps ?
    Par fb57 dans le forum OpenGL
    Réponses: 3
    Dernier message: 23/09/2004, 21h22

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo