estructura de directorios para una biblioteca de C ++

StackOverflow https://stackoverflow.com/questions/1398445

Pregunta

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

Por lo tanto, me siento una limpieza está en orden. La primera cosa que me gustaría mejorar es la estructura de directorios del proyecto. Me gustaría crear una estructura que es adecuado para las herramientas Automake para permitir una fácil compilación de múltiples plataformas, pero nunca he utilizado estos antes. Dado que todavía va a realizar (la mayor parte del) que codifica en Visual Studio, necesitaré un lugar para mantener los archivos de proyecto y la solución de Visual Studio también.

Traté de Google para términos como "C ++ estructura de directorios de la biblioteca", pero nada parece útil para llegar. He encontrado algunas pautas básicas, pero sin soluciones claras cristalinas.

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

Yo no tengo / poca experiencia previa con el desarrollo multi-plataforma / proyectos de código abierto y estoy bastante sorprendido de que no puedo encontrar ninguna directriz buenas sobre cómo estructurar un proyecto de este tipo.

¿Cómo se debe estructurar en general, un proyecto tan biblioteca? Lo que el ca se recomienda leer? ¿Hay algunos ejemplos de buenas?

¿Fue útil?

Solución

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 un tanto refleja el sistema de archivos 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, estos pueden terminar en /usr/local (que es la instalación por defecto prefijo para GNU autoconf), y no puede adherirse a esta estructura en absoluto.

No hay ninguna regla dura y rápida. Yo personalmente no organizar 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 tiene sentido para usted (y su equipo). Hacer lo que es más sensato para el entorno de desarrollo elegido, herramientas de construcción y control de origen.

Otros consejos

No creo que en realidad hay ninguna directriz buenos para esto. La mayor parte es sólo preferencia personal. Ciertos de IDE determinarán una estructura básica para usted, sin embargo. Visual Studio, por ejemplo, se creará una carpeta del compartimiento separado que se divide en una versión de depuración y subcarpetas. En VS, esto tiene sentido cuando se está compilando el código utilizando diferentes objetivos. (El modo de depuración, Release modo.)

Como dice greyfade, utilizar un diseño que tenga sentido para usted. Si alguien no le gusta, que sólo tendrán que reestructurar por sí mismos. Afortunadamente, la mayoría de los usuarios estarán encantados con la estructura que ha elegido. (A menos que sea real desordenado.)

Me parece biblioteca wxWidgets (open source) es un buen ejemplo. Apoyan muchas plataformas diferentes (Win32, Mac OS X, Linux, FreeBSD, Solaris, la mueca de dolor ...) y compiladores (MSVC, CCG, CodeWarrior, Watcom, etc.). Se puede ver la distribución de árbol aquí:

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

No es este impresionante convención que recientemente me encontré con que pueden ser útiles: El diseño Pitchfork (también en GitHub ).

En resumen, la subsección 1.3 establece que:

  

PFL prescribe varios directorios que deben aparecer en la raíz del árbol del proyecto. No todos los directorios son necesarios, pero tienen un propósito asignado, y ningún otro directorio en el sistema de archivos puede asumir el papel de uno de estos directorios. Es decir, estos directorios deben ser los utilizados si se requiere su propósito.

     

Otros directorios no debe aparecer en la raíz.

     

build/: un directorio especial que no debe ser considerado como parte de la fuente del proyecto. Se utiliza para almacenar los resultados de compilación efímeras. No se debe comprobar en control de código fuente. Si el uso de control de origen, debe ser ignorado el uso de control de origen ignore-listas.

     

src/: Ciudad principal fuente compilables. Deben estar presentes para proyectos con componentes compilados que no utilizan submódulos.   En presencia de include/, también contiene las cabeceras privadas.

     

include/: Directorio de cabeceras públicas. Puede estar presente. Puede omitirse en caso de proyectos que no distinguen entre las cabeceras privadas / públicas. Puede omitirse en caso de que los proyectos de submódulos de uso.

     

tests/:. Directorio para las pruebas

     

examples/:. Directorio para las muestras y ejemplos

     

external/:. Directorio de paquetes / proyectos a ser utilizados por el proyecto, pero no editar como parte del proyecto

     

extras/:. Directorio que contiene extra / submódulos opcionales para el proyecto

     

data/: Directorio que no contienen fuente de código aspectos del proyecto. Esto podría incluir gráficos y archivos de marcado.

     

tools/: Directorio que contiene las utilidades de desarrollo, tales como la construcción y guiones refactorización

     

docs/:. Directorio para la documentación del proyecto

     

libs/:. Directorio de submódulos principales del proyecto

Además, creo que el directorio extras/ es donde sus enlaces Python debe ir .

Me puede recomendar realmente que usando CMake ... es para el desarrollo multiplataforma y es mucho más flexible que automake, el uso CMake y usted será capaz de escribir código de plataforma cruzada con su propia estructura direcory en todos los sistemas.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top