2009-09-09 23 views
60

Estoy trabajando en una biblioteca C++. En última instancia, me gustaría que esté disponible públicamente para múltiples plataformas (al menos Linux y Windows), junto con algunos ejemplos y enlaces Python. El trabajo está progresando muy bien, pero por el momento el proyecto es bastante desordenado, construido únicamente en y para Visual C++ y no multiplataforma en absoluto.Estructura de directorios para una biblioteca C++

Por lo tanto, siento que la limpieza está en orden. Lo primero que me gustaría mejorar es la estructura de directorios del proyecto. Me gustaría crear una estructura que sea adecuada para las herramientas Automake para permitir una compilación fácil en múltiples plataformas, pero nunca las he usado antes. Como todavía estaré haciendo (la mayoría de) la codificación en Visual Studio, también necesitaré un lugar para mantener mi proyecto de Visual Studio y los archivos de la solución.

Intenté buscar en Google términos como "Estructura de directorios de la biblioteca C++", pero parece que no aparece nada útil. Encontré algunas pautas muy básicas, pero no hay soluciones claras.

Mientras observa algunas librerías de código abierto, se me ocurrió lo siguiente:

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

que no tengo poca experiencia/anterior con el desarrollo multi-plataforma/proyectos de código abierto y estoy bastante sorprendido de que no puedo encontrar cualquier buena guía sobre cómo estructurar tal proyecto.

¿Cómo se debe estructurar en general un proyecto de biblioteca de este tipo? ¿Qué se recomienda leer? ¿Hay algunos buenos ejemplos?

+0

que parece ser un duplicado de http://stackoverflow.com/questions/1383174/source-file-organisation/1383188#1383188 –

Respuesta

80

Una cosa que es muy común entre las bibliotecas de Unix es que están organizados de tal manera 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` 

Es algo refleja el sistema de archivos de Unix tradicional bajo /usr donde:

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

Por supuesto, éstas podrán terminan en /usr/local (que es el prefijo de instalación predeterminado para GNU autoconf), y es posible que no se adhieran a esta estructura.

No hay una regla rígida. Yo personalmente no organizo las cosas de esta manera. (Evito el uso de un directorio ./src/ en absoluto a excepción de los proyectos más grandes, por ejemplo. También no utilizo autotools, prefiriendo en lugar de CMake.)

Mi sugerencia para usted es que usted debe elegir una disposición de directorios que marcas sentido para usted (y su equipo). Haga lo que sea más sensato para su entorno de desarrollo elegido, herramientas de compilación y control de origen.

+3

Al utilizar CMake, OUT- de la fuente de construcción parece genial. – Korchkidu

5

No creo que haya realmente buenas pautas para esto. La mayor parte es solo preferencia personal. Sin embargo, ciertos IDE determinarán una estructura básica para ti. Visual Studio, por ejemplo, creará una carpeta bin separada que se divide en una subcarpeta Debug and Release. En VS, esto tiene sentido cuando compilas tu código usando diferentes objetivos. (Modo de depuración, modo de liberación)

Como dice greyfade, use un diseño que tenga sentido para usted. Si a alguien más no le gusta, tendrán que reestructurarlo ellos mismos. Afortunadamente, la mayoría de los usuarios estarán contentos con la estructura que ha elegido. (A menos que sea realmente complicado)

4

La biblioteca wxWidgets (código abierto) me parece un buen ejemplo. Son compatibles con muchas plataformas diferentes (Win32, Mac OS X, Linux, FreeBSD, Solaris, WinCE ...) y compiladores (MSVC, GCC, CodeWarrior, Watcom, etc.). Se puede ver la distribución de árbol aquí:

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

Cuestiones relacionadas