Structure de répertoire pour une bibliothèque C++

Question

Je travaille sur une bibliothèque C++. En fin de compte, je voudrais le rendre publiquement disponible pour plusieurs plates-formes (Linux et Windows au moins), avec quelques exemples et Python liaisons. Le travail progresse bien, mais pour le moment, le projet est assez compliqué, construit uniquement dans et pour Visual C++ et pas multi-plateforme du tout. Par conséquent, je pense qu'un nettoyage est en ordre. La première chose que j'aimerais améliorer est la structure du répertoire du projet. Je voudrais créer une structure qui convient aux outils Automake pour permettre une compilation facile sur plusieurs plateformes, mais je ne les ai jamais utilisées auparavant. Puisque je ferai encore (la plupart du temps) du codage dans Visual Studio, j'aurai besoin de quelque part pour garder mes fichiers de projet et de solution Visual Studio.

J'ai essayé de google pour des termes comme "structure de répertoire de bibliothèque C++", mais rien d'utile ne semble venir. J'ai trouvé quelques directives très simples, mais pas de solutions claires.

Tout en regardant certaines bibliothèques open source, je suis venu avec les éléments suivants:

\mylib 
    \mylib <source files, read somewhere to avoid 'src' directory> 
     \include? or just mix .cpp and .h 
    \bin <compiled examples, where to put the sources?> 
    \python <Python bindings stuff> 
    \lib <compiled library> 
    \projects <VC++ project files, .sln goes in project root?> 
    \include? 
    README 
    AUTHORS 
    ... 

Je n'ai pas/peu d'expérience avec le développement multi-plateforme/projets open source et je suis très étonné que je ne trouve pas de bonnes directives sur la façon de structurer un tel projet.

Comment devrait-on généralement structurer un tel projet de bibliothèque? Quel peut être recommandé de lire? Y a-t-il de bons exemples?

Answer 1

Une chose qui est très commun entre les bibliothèques Unix est qu'ils sont organisés de telle sorte que:

./   Makefile and configure scripts. 
./src  General sources 
./include Header files that expose the public interface and are to be installed 
./lib  Library build directory 
./bin  Tools build directory 
./tools Tools sources 
./test  Test suites that should be run during a `make test` 

Il reflète un peu le système de fichiers Unix traditionnel sous /usr où:

/usr/src  Sometimes contains sources for installed programs 
/usr/include Default include directory 
/usr/lib  Standard library install path 
/usr/share/projectname Contains files specific to the project. 

Bien sûr, ceux-ci peuvent finissent par /usr/local (qui est le préfixe d'installation par défaut pour GNU autoconf), et ils peuvent ne pas adhérer à cette structure du tout.

Il n'y a pas de règle stricte. Personnellement, je n'organise pas les choses de cette façon. (J'éviter d'utiliser un répertoire ./src/ du tout, sauf pour les plus grands projets, par exemple. Je n'utilise aussi autotools, préférant à la place CMake.)

Ma suggestion pour vous est que vous devez choisir une mise en page d'annuaire marques sens pour vous (et votre équipe). Faites tout ce qui est le plus adapté à l'environnement de développement, aux outils de construction et au contrôle des sources que vous avez choisis.

Answer 2

Je ne pense pas qu'il y ait vraiment de bonnes directives pour cela. La plupart de cela est juste une préférence personnelle. Certains IDE vont déterminer une structure de base pour vous, cependant. Visual Studio, par exemple, créera un dossier bin séparé qui est divisé dans un sous-dossier Debug et Release. Dans VS, cela est logique lorsque vous compilez votre code en utilisant différentes cibles. (Mode de débogage, mode de relâchement.)

Comme le dit la greyfade, utilisez une disposition qui a du sens pour vous. Si quelqu'un d'autre ne l'aime pas, ils devront simplement le restructurer eux-mêmes. Heureusement, la plupart des utilisateurs seront satisfaits de la structure que vous avez choisie. (À moins que ce ne soit vraiment en désordre.)

Answer 3

Je trouve que la bibliothèque wxWidgets (open source) est un bon exemple. Ils supportent de nombreuses plateformes différentes (Win32, Mac OS X, Linux, FreeBSD, Solaris, WinCE ...).) et les compilateurs (MSVC, GCC, CodeWarrior, Watcom, etc.). Vous pouvez voir la mise en page d'arbre ici:

https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk/