Estructura de directorio para una biblioteca C ++

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

Por lo tanto, creo que es necesario realizar una limpieza. 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 de Automake para permitir una fácil compilación en múltiples plataformas, pero nunca antes las había usado. Como todavía estaré haciendo (la mayor parte) de la codificación en Visual Studio, necesitaré un lugar para guardar mi proyecto de Visual Studio y los archivos de solución también.

Intenté buscar en Google términos como "estructura de directorio de la biblioteca C ++", pero parece que no surge nada útil. Encontré algunas pautas muy básicas, pero no soluciones claras como el cristal.

Mientras miraba algunas bibliotecas 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
    ...

No tengo o tengo poca experiencia previa con proyectos de código abierto / desarrollo multiplataforma y estoy bastante sorprendido de que no puedo encontrar ninguna buena guía sobre cómo estructurar un proyecto de este tipo.

¿Cómo se debería estructurar en general un proyecto de biblioteca de este tipo? ¿Qué se puede recomendar leer? ¿Hay buenos ejemplos?

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

De alguna manera refleja el sistema de archivos tradicional de Unix bajo /usrdonde:

/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 el prefijo de instalación predeterminado para GNU autoconf), y es posible que no se adhieran a esta estructura en absoluto.

No hay una regla estricta. Yo personalmente no organizo las cosas de esta manera. (Evito usar un./src/ directorio en absoluto, excepto para los proyectos más grandes, por ejemplo. Tampoco uso autotools, prefiero CMake).

Mi sugerencia es que elija un diseño de directorio que tenga sentido para usted (y su equipo). Haga lo que sea más sensato para su entorno de desarrollo elegido, compile herramientas y control de código fuente.

Existe una convención increíble que encontré recientemente que podría ser útil: El diseño de Pitchfork (también en GitHub ).

En resumen, la subsección 1.3 establece que:

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

Otros directorios no deberían aparecer en la raíz.

build/: Un directorio especial que no debe considerarse parte del origen del proyecto. Se utiliza para almacenar resultados de compilación efímeros. no se debe registrar en el control de fuente. Si usa control de fuente, debe ignorarse usando listas de ignorar de control de fuente.

src/: Ubicación de la fuente principal compilable. Debe estar presente para proyectos con componentes compilados que no usan submódulos. En la presencia deinclude/ , también contiene encabezados privados.

include/: Directorio para encabezados públicos. Puede estar presente. Puede omitirse para proyectos que no distinguen entre encabezados privados / públicos. Puede omitirse para proyectos que usan submódulos.

tests/: Directorio de pruebas.

examples/: Directorio de muestras y ejemplos.

external/: Directorio de paquetes / proyectos que el proyecto utilizará, pero que no se editará como parte del proyecto.

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

data/: Directorio que contiene aspectos del proyecto que no son de código fuente. Esto puede incluir gráficos y archivos de marcado.

tools/: Directorio que contiene utilidades de desarrollo, como scripts de compilación y refactorización

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

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

Además, creo que el extras/directorio es donde deberían ir sus enlaces de Python .

No creo que haya buenas pautas para esto. La mayor parte es solo preferencia personal. Sin embargo, ciertos IDE determinarán una estructura básica para usted. Visual Studio, por ejemplo, creará una carpeta bin separada que se divide en las subcarpetas Debug y Release. En VS, esto tiene sentido cuando está compilando su código usando diferentes destinos. (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á que reestructurarlo ellos mismos. Afortunadamente, la mayoría de los usuarios estarán satisfechos con la estructura que ha elegido. (A menos que sea realmente complicado).

Creo que la biblioteca wxWidgets (código abierto) es un buen ejemplo. Soportan muchas plataformas diferentes (Win32, Mac OS X, Linux, FreeBSD, Solaris, WinCE ...) y compiladores (MSVC, GCC, CodeWarrior, Watcom, etc.). Puedes ver el diseño del árbol aquí:

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

Realmente puedo recomendarle que use CMake ... es para desarrollo multiplataforma y es mucho más flexible que automake, use CMake y podrá escribir código multiplataforma con su propia estructura de directorios en todos los sistemas.