2009-09-09 9 views
60

Ich arbeite an einer C++ - Bibliothek. Letztendlich möchte ich es für mehrere Plattformen (zumindest Linux und Windows) öffentlich zugänglich machen, zusammen mit einigen Beispielen und Python Bindings. Die Arbeit schreitet gut voran, aber im Moment ist das Projekt ziemlich unordentlich, nur in und für Visual C++ gebaut und nicht Multi-Plattform.Verzeichnisstruktur für eine C++ - Bibliothek

Daher fühle ich eine Reinigung in Ordnung ist. Das erste, was ich verbessern möchte, ist die Verzeichnisstruktur des Projekts. Ich möchte eine Struktur erstellen, die für die Automake Tools geeignet ist, um eine einfache Kompilierung auf mehreren Plattformen zu ermöglichen, aber ich habe diese zuvor noch nie verwendet. Da ich in Visual Studio immer noch (größtenteils) codiere, brauche ich irgendwo auch meine Visual Studio Projekt- und Lösungsdateien.

Ich habe versucht, nach Begriffen wie "C++ Bibliothek Verzeichnisstruktur" googeln, aber nichts nützliches scheint zu kommen. Ich fand einige sehr grundlegende Richtlinien, aber keine kristallklaren Lösungen.

Während bei einigen Open-Source-Bibliotheken suchen, kam ich mit der Follow-up:

\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 
    ... 

Ich habe keine/wenig Erfahrung mit Multi-Plattform-Entwicklung/Open-Source-Projekten und bin ganz erstaunt, dass ich nicht finden kann, irgendwelche guten Richtlinien, wie man solch ein Projekt strukturiert.

Wie sollte man ein solches Bibliotheksprojekt generell strukturieren? Was kann zum Lesen empfohlen werden? Gibt es einige gute Beispiele?

+0

Scheint wie ein Duplikat http://stackoverflow.com/questions/1383174/source-file-organisation/1383188#1383188 –

Antwort

80

Eine Sache, die unter Unix-Bibliotheken sehr häufig ist, dass sie organisiert sind, so dass:

./   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` 

Es spiegelt ein wenig die traditionelle Unix-Dateisystem unter /usr wo:

/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. 

Natürlich können diese Ende in /usr/local (das ist das Standard-Installationspräfix für GNU Autoconf), und sie möglicherweise nicht diese Struktur überhaupt einhalten.

Es gibt keine feste Regel. Ich persönlich organisiere die Dinge nicht so. (Ich vermeide mit einem ./src/ Verzeichnis auf alle mit Ausnahme der größten Projekte, zum Beispiel. Ich glaube nicht, auch Autotools verwenden, statt dem lieben CMake.)

Sie Mein Vorschlag ist, dass Sie ein Verzeichnis Layout wählen sollen, dass Marken Sinn für Sie (und Ihr Team). Tun Sie alles, was für Ihre gewählte Entwicklungsumgebung, Build-Tools und Quellcodeverwaltung am sinnvollsten ist.

+3

Wenn CMake verwenden, out- der Quellcode scheint groß zu sein. – Korchkidu

5

Ich glaube nicht, dass es tatsächlich irgendwelche guten Richtlinien dafür gibt. Das meiste ist nur persönliche Vorliebe. Bestimmte IDEs bestimmen jedoch eine grundlegende Struktur für Sie. Visual Studio erstellt beispielsweise einen separaten Ordner, der in die Unterordner Debug und Release unterteilt ist. In VS ist dies sinnvoll, wenn Sie Ihren Code mit verschiedenen Zielen kompilieren. (Debug-Modus, Freigabemodus.)

Da Greefade sagt, verwenden Sie ein Layout, das für Sie sinnvoll ist. Wenn es einem anderen nicht gefällt, müssen sie es nur selbst umstrukturieren. Glücklicherweise werden die meisten Benutzer mit der von Ihnen gewählten Struktur zufrieden sein. (Es sei denn, es ist wirklich chaotisch.)

4

Ich finde wxWidgets Bibliothek (Open Source), um ein gutes Beispiel zu sein. Sie unterstützen viele verschiedene Plattformen (Win32, Mac OS X, Linux, FreeBSD, Solaris, WinCE ...) und Compiler (MSVC, GCC, CodeWarrior, Watcom usw.). Sie können den Baum Layout sehen hier:

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