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

Question

Je suis en train de travailler sur une bibliothèque C++. En fin de compte, je tiens à le rendre accessible au public pour de multiples plates-formes (Linux et Windows au moins), avec des exemples et Python bindings. Les travaux avancent bien, mais au moment où le projet est assez bordélique, construit uniquement dans et pour Visual C++ et pas de multi-plate-forme à tous.

Donc, je pense qu'un nettoyage est en ordre. La première chose que je voudrais améliorer la structure de répertoire du projet. Je voudrais créer une structure qui est adapté pour les Automake outils pour faciliter la compilation sur de multiples plates-formes, mais je n'ai jamais utilisé avant. Depuis que je vais encore être en train de faire (la plupart des) codage dans Visual Studio, je vais avoir besoin d'un endroit pour garder mon projet Visual Studio et les fichiers de solution.

J'ai essayé de google pour les termes "de la bibliothèque C++ structure de répertoire", mais rien d'utile ne semble venir. J'ai trouvé quelques très directives de base, mais pas de cristal clair solutions.

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 antérieure avec multi-plate-forme de développement/projets open source et je suis assez étonné de voir que je ne trouve pas les bonnes lignes directrices sur la façon de structurer un tel projet.

Comment doit-on généralement de la structure, un projet de bibliothèque? Ce que ca sera recommandé de lire? Existe-il des exemples?

Answer 1

Une chose qui est très commun parmi Unix bibliothèques, c'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 traditionnel système de fichiers Unix, en vertu de l' /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, il peut finir en /usr/local (ce qui est l'installation par défaut de préfixe pour GNU autoconf), et ils ne peuvent pas adhérer à cette structure.

Il n'y a pas difficile et rapidement la règle. Personnellement, je ne pas organiser les choses de cette façon. (Je ne peux pas utiliser un ./src/ répertoire du tout, sauf pour les plus gros projets, par exemple. Je n'ai pas utiliser les autotools, préférant CMake.)

Ma suggestion pour vous est que vous devez choisir un répertoire de mise en page qui fait sens pour vous (et votre équipe). Faire tout ce qui est plus logique pour votre environnement de développement choisi, outils de création et de contrôle de source.

Answer 2

Je trouve que la bibliothèque wxWidgets (open source) est un bon exemple. Ils supportent de nombreuses plates-formes différentes (Win32, Mac OS X, Linux, FreeBSD, Solaris, WinCE ...) et des compilateurs (MSVC, GCC, CodeWarrior, Watcom, etc.). Vous pouvez voir la disposition de l'arbre ici:

http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/

Answer 3

Je ne pense pas qu'il y a en fait toute de bonnes lignes directrices pour cela. La plupart de c'est juste une préférence personnelle. Certains IDE sera de déterminer une structure de base pour vous, cependant. Visual Studio, par exemple, créer un dossier bin qui est divisé en un Debug et Release des sous-dossiers. Dans VS, cela a du sens lorsque vous compilez votre code à l'aide de différentes cibles. (Mode Debug, Release mode).

Comme greyfade dit, utiliser une mise en page qui fait sens pour vous. Si quelqu'un d'autre ne l'aime pas, ils ont juste à se restructurer eux-mêmes. Heureusement, la plupart des utilisateurs vont être heureux avec la structure que vous avez choisie. (Sauf si c'est réel désordre.)