Meilleure structure de dossiers pour les bibliothèques et les liaisons C++ multiplateformes

Question

Je suis sur le point de commencer à travailler sur une bibliothèque multiplateforme qui sera écrite en C++. Plus tard, j'ai l'intention d'implémenter des liens pour d'autres langages tels que Python, Java, etc. La bibliothèque doit être disponible sur les principales plateformes : win32, Linux et Mac OSX.

Bien que l'application soit en réalité une bibliothèque, quelques programmes de base pour la console seront fournis avec elle à des fins de démonstration et de test.

J'aimerais trouver une structure de dossier optimale avant de commencer à stocker des choses dans Subversion.

Je pense à quelque chose comme :

/project                    //Top level folder

        /bin                //Binaries ready for deployment
            /linux_amd64    //Linux AMD64 platform
                  /debug    //Debug build - duplicated in all platforms
                  /release  //Release build - duplicated in all platforms
            /linux_i386     //Linux 32-bit platform
            /macosx         //Mac OS X
            /win32          //Windows 32-bit platform
                  /cygwin   //Windows 32-bit platform compiled with Cygwin
                  /vs.net   //Windows 32-bit platform compiled with Visual Studio .NET
            /win64          //Windows 64-bit platform

        /build              //Make and build files, IDE project files
            /linux_amd64    //Linux AMD64 platform
            /linux_i386     //Linux 32-bit platform
            /macosx         //Mac OS X
            /win32          //Windows 32-bit platform
            /win64          //Windows 64-bit platform

        /config             //Configuration files that accompany the binaries

        /data               //Data files that accompany the binaries

        /doc                //Documentation

        /lib                //External or third-party libraries
            /platforms      //Platform-specific code for ...
                      /linux_amd64    //Linux AMD64 platform
                      /linux_i386     //Linux 32-bit platform
                      /macosx         //Mac OS X
                      /win32          //Windows 32-bit platform
                      /win64          //Windows 64-bit platform
            /src            //Available library source code in subfolders

        /src                //Source code tree - this will contain main.cpp
            /bindings       //Bindings to other languages such as ...
                      /python
                      /java
            /h              //Header files
            /modules        //Platform-independent modules, components or subprojects
            /platforms      //Platform-specific code for ...
                      /linux_amd64 //Linux AMD64 platform-specific code
                      /linux_i386  //Linux 32-bit platform-specific code
                      /macosx
                      /win32       //Windows 32-bit platform-specific code
                      /win64       //Windows 64-bit platform

        /test               //Automated test scripts

Si vous avez des suggestions, je serais ravi de les entendre. Je me demande s'il existe un outil qui peut aider à créer cette structure.

J'ai l'intention d'utiliser CMake et Subversion.

Answer 1

La structure me semble bonne, mais il y a quelques points :

• il est normal de séparer les fichiers d'en-tête C++ et les fichiers sources dans des répertoires différents, ou peut-être y a-t-il une structure dans le répertoire des modules que vous ne montrez pas ?
• vous voulez probablement des répertoires pour y placer des fichiers intermédiaires comme *.obj
• vous aurez besoin de répertoires différents pour les fichiers de sortie de débogage et de sortie de version.
• un répertoire pour les installateurs comme InnoSetup et leurs fichiers d'installation peut être utile - vous devez prendre la décision philosophique de contrôler ou non la version de ces fichiers.

Quant aux outils pour créer la structure, quelques minutes passées à écrire un bash script suffisent - il est intéressant d'avoir les mêmes outils (comme bash) disponibles sur toutes les plateformes.

Answer 2

Pourquoi avez-vous besoin de dossiers de plateformes différentes pour les fichiers binaires ? Vous allez construire ce code source sous différentes plateformes mais avec le même système de fichiers ?

Si oui, je pense que vous avez également besoin de dossiers spécifiques au compilateur.

Pourquoi n'utilisez-vous pas des dossiers différents pour les builds de débogage et de version, peut-être unicode et non-unicode, single-threading ou multithreading ?

Regardez sur bjam ou Scons font des remplaçants. Peut-être n'avez-vous pas besoin de dossiers différents dans le répertoire de construction.

Je pense que ce serait mieux si tous les modules du répertoire "modules" contenaient le répertoire "tests" pour les tests personnels.

---

Et enfin - voir la bibliothèque boost, cette platofrm bibliothèque indépendante qui a une belle structure.

Essayez également d'obtenir des idées de projets indépendants d'autres plateformes.

Renforcer la structure des dossiers :

boost - root dir
- boost - library header lib ( for users )
- libs - library source dir ( one dir per lib )
    - build - library build files ( if they are needed )
    - doc - documentation files
    - example - sample programs
    - src - library source files
    - test - programs and srcipts for testing module
- bin - created by bjam build system
    - libs
        - <lib-name>
            for all compiled folders from libs [example|test|build]
                - <compiler-name>/<[static|dynamic]-link>/<[debug|release]>/<[threading mode]>
                    contain builded [obj|dll|lib|pdb|so|o|etc] files see detailed information in bjam build system

- doc
- tools

Si vous choisissez bjam - vous ne serez pas concerné par la structure des dossiers build et bin.

De même, votre répertoire libs/src/ pourrait contenir des fichiers propres à toutes les plateformes et deux répertoires pour les fichiers spécifiques à une plateforme.

Je ne vois pas de problèmes sérieux dans la structure de vos dossiers, peut-être les verrez-vous lorsque vous commencerez à écrire le prototype du projet.

Answer 3

J'ai récemment publié un question sur l'emballage des en-têtes dans un seul annuaire, j'ai décidé d'opter pour un petit nombre d'annuaires d'inclusion.

Allez-vous prendre en charge Win64 ? Ce sera une cible de plus en plus importante.

Faites pas mettre vos fichiers intermédiaires de construction n'importe où sous un arbre qui est vérifié dans svn. Si vous le faites, en fonction de vos outils clients svn, ils généreront beaucoup de bruit en tant que qui ne sont pas dans le référentiel. Il est donc difficile de voir les fichiers que vous avez ajoutés. devrait être dans le référentiel.

Au lieu de cela, si votre compilateur le permet, mettez les répertoires intermédiaires sur le côté.

Sinon, assurez-vous d'ajouter l'ensemble des répertoires intermédiaires à vos propriétés d'exclusion svn. Certaines interfaces graphiques rendent cela plus facile que d'autres (Tortoise sous Windows, Cornerstone ou Versions sous OS/X).