uso - Estructura de directorio para una biblioteca C++
que hace#include en c++ (3)
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 de Python . El trabajo está progresando muy bien, pero por el momento el proyecto es bastante complicado, construido únicamente para Visual C ++ y no multiplataforma en absoluto.
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 de 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 términos como "estructura de directorio de bibliotecas C ++" en google, pero parece que no aparece nada útil. Encontré algunas pautas muy básicas, pero no hay soluciones claras.
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 / tengo poca experiencia previa con proyectos de desarrollo multiplataforma / open source y estoy bastante sorprendido de que no pueda encontrar ninguna buena guía sobre cómo estructurar un proyecto así.
¿Cómo debería estructurarse un proyecto de biblioteca de este tipo? ¿Qué se recomienda leer? ¿Hay algunos buenos ejemplos?
Encuentro la biblioteca wxWidgets (fuente abierta) como 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í:
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 lanzamiento)
Como dice greyfade, usa un diseño que tenga sentido para ti. 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 desordenado)
Una cosa que es muy común entre las bibliotecas de Unix es que están organizadas 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`
De alguna manera refleja el sistema de archivos Unix tradicional en /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 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. ( ./src/ usar un directorio ./src/ , excepto los proyectos más grandes, por ejemplo. Tampoco uso autotools, prefiero CMake).
Mi sugerencia para usted es que debe elegir 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, herramientas de compilación y control de origen.