Je suis sur le point d'ouvrir un projet C++ sur Sourceforge. Puis-je obtenir des conseils sur l'organisation du code?

Question

Je suis sur le point de télécharger un projet sur lequel j'ai travaillé sur Sourceforge sous la GPL, et j'espérais obtenir des conseils sur la façon d'organiser le code d'une manière facile à comprendre et à utiliser par les développeurs qui pourraient regarde ça, ça marche bien avec git, et la façon dont Sourceforge présente les choses.

Mes projets est une application de C++ multi-plateforme, et se compose des éléments suivants:

• Une partie de la bibliothèque, qui effectue le travail réel
• Une partie de l'interface graphique séparée, qui utilise la partie de la bibliothèque
• Bibliothèques à source ouverte, dont les chemins d'inclusion sont nécessaires pour compiler la bibliothèque
• Les bibliothèques open source modifiées, qui ont été modifiées, sont donc en quelque sorte une partie directe de ce projet
• Sortie compilée de toutes les bibliothèques

Quelle est la meilleure façon d'organiser cela?

Tout en travaillant sur moi-même, à partir de la racine du projet, je l'ai comme ceci:
/LibPortion
/GuiPortion
/libs/bibliothèques open source
/libs/modifiées bibliothèques open source
/libs/compilé/pour contenir les bibliothèques compilées, y compris lors de la compilation pour Windows certaines qui ne proviennent pas des bibliothèques open source, telles que les fichiers de la bibliothèque Cygwin

Est-ce une façon intelligente d'organiser les choses? Est-ce que cela correspond aux conventions et aux attentes?

Lors de la vérification de mon projet, est-il sensé de vérifier dans les bibliothèques open source ainsi que dans le cadre du projet? Je pense qu'il est logique de le faire, car cela minimise les frictions avec la mise en place du projet pour un nouveau dev. Certainement je devrais au moins vérifier dans les bibliothèques open source modifiées.

En outre, qu'est-ce qu'il est logique d'inclure dans le référentiel sous les bibliothèques compilées? Je pense qu'il vaudrait mieux dire à git d'ignorer ce répertoire et de le laisser vide, puisque son contenu sera différent sur chaque cible de construction, puisque mon projet est multi-plateforme.

Cependant, il semble également très bien pour les personnes qui ne veulent pas se tracasser avec la construction et/ou le téléchargement de toutes les bibliothèques elles-mêmes pour offrir les bibliothèques pré-compilées pour les plates-formes majeures. Quelle est la manière la plus intelligente de partager également ceux-là? Je regarde Sourceforge, et il n'est pas évident pour moi de savoir comment je devrais les partager, sinon dans le cadre de mon dépôt git.

Answer 1

En général, séparez votre travail de celui de tiers. Au niveau le plus élémentaire, votre dossier racine pourrait ressembler à:

|- GUI 
|- Library 
|- Third-party 
    |- lib 
    |- source 

Je sépare le dossier « tiers » en deux sous-dossiers aux fins de la conformité des licences et la facilité d'utilisation. La manière exacte dont vous distribuez les bibliothèques tierces dépend entièrement de leurs licences. Configurez vos makefiles pour que les bibliothèques compilées atterrissent dans le dossier third-party\lib (où vous placerez également les bibliothèques précompilées). De cette façon, l'utilisateur peut télécharger les bibliothèques précompilées et ignorer le dossier source ou télécharger le code source et ignorer le dossier lib selon qu'il souhaite ou non reconstruire les bibliothèques tierces.

Si vous devez distribuer votre version modifiée sous forme binaire et sous forme de code source, vous devrez héberger votre version modifiée dans votre référentiel source (à condition de disposer d'une bibliothèque précompilée). Si vous utilisez une bibliothèque non modifiée et que vous utilisez un référentiel Subversion (ou similaire), vous pouvez utiliser la propriété externals pour lier votre référentiel au référentiel de la bibliothèque tierce de sorte que lorsqu'un utilisateur obtient une copie de votre source code, il saisit la source de la lib de son propre repo. De cette façon, vous n'avez pas besoin de garder un miroir local de la source de la bibliothèque. En fonction de la disponibilité de la bibliothèque tierce dans son référentiel, vous pouvez également utiliser des liens externes pour créer un lien vers une version précompilée de la bibliothèque tierce. Cela réduira non seulement la quantité de code que vous devrez héberger dans votre dépôt, mais indiquera également plus clairement que la bibliothèque tierce particulière n'a pas été modifiée. Lorsque vous utilisez des bibliothèques non modifiées, il est préférable de ne pas inclure la source ou le binaire dans votre arborescence source. Notez simplement dans votre documentation que votre projet dépend de la bibliothèque X (spécifiez également la version, si elle est importante) et fournissez un lien vers la page d'accueil du projet/Sourceforge/référentiel de cette bibliothèque. Laissez le développeur décider s'il veut compiler la bibliothèque, télécharger une version pré-compilée ou éventuellement utiliser la version déjà installée. Cela signifie que vous ne pouvez pas non plus supposer que la bibliothèque ou ses en-têtes existeront dans un répertoire particulier par rapport à votre code source; à la place, vous devrez faire confiance à l'utilisateur pour installer les bibliothèques où le compilateur peut les trouver. Votre code supposera simplement qu'ils sont dans le chemin de recherche du compilateur.

Il est également possible que vos bibliothèques modifiées soient implémentées de telle sorte qu'une propriété externe provoque le retrait de la source non modifiée du dépôt tiers et que votre système de construction puisse appliquer un correctif contenant vos modifications. De cette façon, techniquement, vous ne distribuerez pas de code modifié, ce qui peut signifier plusieurs termes de licence auxquels vous devez vous conformer.

En règle générale, je ne recommanderais pas de distribuer des versions précompilées de votre bibliothèque dans votre référentiel source. Avec Sourceforge, vous pouvez pré-compiler votre bibliothèque (ou tout autre «produit final») pour les plateformes majeures et les proposer en téléchargement.

Answer 2

Si j'étais vous je séparerais d'abord le projet entre votre propre code et les bibliothèques de tiers. L'arbre suivant pourrait fonctionner:

/ 
|- GUI 
|- lib 
|- third parties 
    |- compiled targets 
    |- "your first library" 
    |- "another library" 
    |- ... 

Vous ne devez pas héberger compilé les bibliothèques de votre référentiel IMHO. Il est plus flexible de laisser les développeurs les compiler sur leur propre ordinateur, mais si vous voulez avoir une archive livrable, elle devrait inclure des bibliothèques précompilées.

Answer 3

/
|- bin - Compiled binaries go here (not submitted to source-control) 
|- build - buildscripts, tools used to build your code. 
|- lib - Compiled libraries go here (not submitted to source-control) 
|- local - (not submitted to source control) 
    |- obj - Compiled object-files (not submitted to source-control) 
    |- msvc - Autogenerated solution files for visual studio (not submitted to source control) (if applicable) 
    |- scripts - Autogenerated script files (if applicable) 
|- units 
    |- libportion 
     |- include - external headers for other units to see 
     |- src 
    |- guiportion 
     |- include 
     |- src 
|- external 
    |- externallib1 
     |- include 
     |- src 

build - simplified build-script calling the correct convention to your buildscripts. 
README - text-file explaining your software and the layout of your source. 

Ceci est l'organisation que j'ai utilisée récemment et elle a été grandement appréciée par tout le monde. Cela facilite également la séparation des bibliothèques entre elles et facilite la fourniture d'en-têtes internes et d'en-têtes externes dans les bibliothèques.

Modifier: Ajout du répertoire "local".

Answer 4

IMHO regardant l'organisation de divers projets open source pourrait aider.

vlc project page peut être une bonne référence