9
votes

Organisation de fichier source

J'ai un peu de difficulté à organiser mes fichiers source.

J'ai mon propre collection de code, mais en croissance croissante que j'aimerais utiliser dans divers projets. La disposition de fichier et de dossier est quelque chose comme ceci:

bibliothèque \ sub1 \ source.h

bibliothèque \ sub1 \ source.cpp

bibliothèque \ sub2 \ Source.h

bibliothèque \ sub2 \ source.cpp

Un de mes problèmes est que je souhaite inclure ce code, selon les besoins, dans mes autres projets. À ce jour, j'ai utilisé des chemins absolus pour pointer vers le code de Libary, mais il doit y avoir une meilleure façon.

FutHermore, j'ai besoin d'ajouter chaque fichier de bibliothèque que j'utilise dans les fichiers de projet Visual Studio afin de pouvoir compiler correctement.

Donc, ma question en bref est comment puis-je résoudre ce problème? Quel est le moyen approprié / meilleur de gérer la situation ci-dessus.


2 commentaires

Pourquoi voulez-vous inclure le code source dans d'autres projets? L'utilisation de fichiers source utilisées dans plusieurs projets de cette manière ad hoc est la folie - vous êtes tenu de modifier un projet qui le casse une autre. Et il supprime également l'un des avantages de l'utilisation de bibliothèques - vous n'avez besoin que de la liberté et non de la source. Essayez d'être plus discipliné - il gagnera du temps à long terme et probablement à court terme. Utilisez un système de contrôle du référentiel et de la version (git, subversion ou autre). Assurez-vous de bien vouloir «la version» et publiez des versions testées / livrées de vos bibliothèques.


Peut-être que cela devrait être une question de wiki communautaire? Il n'y a pas une réponse, mais c'est plus une discussion sur l'organisation de fichiers source.


4 Réponses :


2
votes

Je ne pense pas qu'il y ait un bon moyen de faire cela - cela dépend de ce que vous essayez de réaliser.

Voici certaines choses que vous pourriez ne pas être au courant:

  • Vous pouvez utiliser des chemins relatifs dans vos projets.

  • Vous pouvez utiliser des variables d'environnement dans des chemins.

  • Vous pouvez ajouter des annuaires aux règles de recherche de Visual Studio.

    Cela vous donne un peu plus de contrôle sur l'endroit où vous mettez les fichiers inclus et si vous ajoutez vos dossiers aux règles de recherche de Visual Studio, vous n'avez pas à inclure des chemins du tout.


0 commentaires

0
votes

Premier: ajoutez tous les répertoires utilisés à votre projet incluent des chemins. Ajoutez-les comme des chemins relatifs si possible.

Deuxièmement: vous devez ajouter toutes les fichiers de bibliothèques / sources d'occasion à votre projet. Cela peut être fait soit fait dans l'explorateur de projet, soit dans l'onglet Project-> Linker. Dans ce dernier cas, vous devrez ajouter également les répertoires utilisés des chemins de bibliothèque de projets.

Habituellement, ce n'est pas une bonne idée d'utiliser des chemins dans #include Directives.


0 commentaires

3
votes

Vous ne devriez pas, en général, ajouter des fichiers source des bibliothèques directement à d'autres projets. Compilez-les séparément comme une bibliothèque et utilisez celles-ci.

Pour organiser la structure de répertoire de la bibliothèque elle-même, je me suis installé maintenant sur quelque chose comme la structure suivante p>

  • bibliothèque1 / widget.h li>
  • Bibliothèque1 / Private / SeulinLib.h Li>
  • bibliothèque1 / privé / widget.cpp li> ul>

    (et le cas échéant) p>

    • bibliothèque1 / privé / ressources / widget.jpg li>
    • bibliothèque1 / privé / projet / widget.xcode li> ul>

      I Mettez tous les en-têtes directement dans le chemin de la bibliothèque et j'ai un sous-dossier privé code> qui contiendra tout ce qui est utilisé uniquement par la bibliothèque, mais ne doit jamais être partagé / exposé. p>

      Le plus grand avantage est que chaque projet que je n'entate que nécessite un chemin d'accès incluant le point de vue du répertoire contenant mes bibliothèques, puis tout (public) include est fait comme p> xxx pré>

      Inclus particuliers sont simplement P>

      #include "onlyinlib.h"
      
      • Si de nouvelles bibliothèques sont introduites, il n'y a pas de mess avec les paramètres de projet / compilateur pour obtenir les en-têtes visibles '. li>
      • Déménager dans d'autres compilateurs / plates-formes est également très peu tracas. Li>
      • Les en-têtes sont automatiquement «noms de noms», c'est-à-dire en incluant une partie du trajet également, il est presque impossible d'obtenir une naméclash avec le Comprend LI>
      • Il est immédiatement évident où une en-tête provient et si un en-tête fait partie de l'interface publique ou non li> ul> p>


0 commentaires

1
votes

Si vous devez inclure un code tiers au lieu de simplement relier une version pré-compilée (par exemple, vous devez peut-être apporter des modifications ou des modifications), considérez ramifiant dans tout ce que vous utilisez. Pour la commande source:

  • / coffre / ... --- votre code va ici
  • / tiersparty --- des copies vierges des bibliothèques tiers vont ici
    • / tiersparty / lib1
    • / tiersparty / lib2
    • etc.
    • / tronc / lib1 --- ramifié de: / tiersparty / lib1, peut-être avec des changements locaux
      • Ceci est la version que vous construisez / lier avec.

        En supposant que vous utilisiez un système de contrôle source décent, ce schéma vous permettra de passer facilement à des versions plus récentes de bibliothèques tiers, puis de fusionner ces modifications avec les modifications que vous avez apportées localement.

        Par exemple, supposons que "la lib1" libère une nouvelle version:

        • commettre le changement à / tiersparty / lib1.
        • fusion de / tiersparty / lib1 to / coffre / lib1
        • réparer tout conflit de fusion.

          Ceci est, IMO, le seul moyen sain de gérer la modernisation des bibliothèques tiers auxquelles vous avez apporté des modifications locales.


0 commentaires