2009-04-05 23 views
51

Estoy a punto de comenzar a trabajar en una biblioteca multiplataforma que se escribirá en C++. En el futuro, pretendo implementar enlaces para otros lenguajes como Python, Java, etc. La biblioteca debe estar disponible en las principales plataformas: win32, Linux y Mac OSX.Mejor estructura de carpetas para C++ biblioteca multiplataforma y enlaces

Aunque la aplicación es realmente una biblioteca, algunos programas básicos de consola se incluirán junto con la misma para demostración y prueba.

Me gustaría obtener una estructura de carpetas óptima antes de comenzar a almacenar cosas en Subversion.

Estoy pensando en algo como:

/project     //Top level folder 

     /bin    //Binaries ready for deployment 
      /linux_amd64 //Linux AMD64 platform 
        /debug //Debug build - duplicated in all platforms 
        /release //Release build - duplicated in all platforms 
      /linux_i386  //Linux 32-bit platform 
      /macosx   //Mac OS X 
      /win32   //Windows 32-bit platform 
        /cygwin //Windows 32-bit platform compiled with Cygwin 
        /vs.net //Windows 32-bit platform compiled with Visual Studio .NET 
      /win64   //Windows 64-bit platform 

     /build    //Make and build files, IDE project files 
      /linux_amd64 //Linux AMD64 platform 
      /linux_i386  //Linux 32-bit platform 
      /macosx   //Mac OS X 
      /win32   //Windows 32-bit platform 
      /win64   //Windows 64-bit platform 

     /config    //Configuration files that accompany the binaries 

     /data    //Data files that accompany the binaries 

     /doc    //Documentation 

     /lib    //External or third-party libraries 
      /platforms  //Platform-specific code for ... 
         /linux_amd64 //Linux AMD64 platform 
         /linux_i386  //Linux 32-bit platform 
         /macosx   //Mac OS X 
         /win32   //Windows 32-bit platform 
         /win64   //Windows 64-bit platform 
      /src   //Available library source code in subfolders 

     /src    //Source code tree - this will contain main.cpp 
      /bindings  //Bindings to other languages such as ... 
         /python 
         /java 
      /h    //Header files 
      /modules  //Platform-independent modules, components or subprojects 
      /platforms  //Platform-specific code for ... 
         /linux_amd64 //Linux AMD64 platform-specific code 
         /linux_i386 //Linux 32-bit platform-specific code 
         /macosx 
         /win32  //Windows 32-bit platform-specific code 
         /win64  //Windows 64-bit platform 

     /test    //Automated test scripts 

Si tiene alguna sugerencia, me encantaría escucharlos. Me pregunto si hay una herramienta que pueda ayudar a crear esta estructura.

Estoy planeando usar CMake y Subversion.

+0

Tengo una pregunta para ti: como es una lib, ¿cuál es la main.cpp y cómo va a ser utilizada por otra persona? Me estoy enfrentando a la pregunta ATM, y creo que main.cpp es en realidad una prueba de la lib. ¿No lo es? –

+1

Tengo una respuesta relacionada aquí: [La mejor (más limpia) forma de escribir el código específico de la plataforma] (https://stackoverflow.com/a/32685299/3258851) –

Respuesta

6

¿Por qué necesita diferentes carpetas de plataforma para archivos binarios? ¿Vas a construir este código fuente bajo diferentes platoforms pero con el mismo sistema de archivos?

En caso afirmativo, creo que también necesita carpetas específicas de compiller.

¿Por qué no utiliza diferentes carpetas para depurar y lanzar compilaciones, tal vez compilaciones unicode y no unicode, de subprocesamiento simple o multiproceso?

Mira en bjam o Scons hacer sustitutos. Tal vez no necesites carpetas diferentes en el directorio de compilación.

Creo que será mejor si todos los módulos del directorio "modules" contendrán el directorio "tests" para autodiagnóstico.


Y la última - ver la biblioteca de impulso, esta biblioteca independiente platofrm que tienen buena estructura.

También intente obtener ideas de otros proyectos independientes de plataforma.

Boost carpetas estructura:

boost - root dir 
- boost - library header lib (for users) 
- libs - library source dir (one dir per lib) 
    - build - library build files (if they are needed) 
    - doc - documentation files 
    - example - sample programs 
    - src - library source files 
    - test - programs and srcipts for testing module 
- bin - created by bjam build system 
    - libs 
     - <lib-name> 
      for all compiled folders from libs [example|test|build] 
       - <compiler-name>/<[static|dynamic]-link>/<[debug|release]>/<[threading mode]> 
        contain builded [obj|dll|lib|pdb|so|o|etc] files see detailed information in bjam build system 

- doc 
- tools 

Si elige bjam - no estar preocupado sobre la estructura y las carpetas bin estructura.

También sus libs/src/dir pueden contener archivos propios para todos los archivos de plataforma y directorios par para archivos específicos de plataforma.

no veo ningún problema serio en sus carpetas estructuran socialmente, tal vez usted los verá cuando el proyecto de escritura inicio prototipo.

+0

No voy a hacer compilación cruzada, es decir, macosx debe ser construido sobre macosx. Tener diferentes carpetas para depurar y liberar es una buena idea. –

+0

Miré el impulso pero no pude ver fácilmente cómo están administrando las plataformas. Parece que están usando el aumento de atasco. –

+0

bjam (boost jam) tiene una curva de aprendizaje empinada, y es más un lenguaje elegante que cualquier otra cosa. No lo recomendaría La mejor alternativa para el make-way que he encontrado es rake; solo porque es flexible, se usa extensivamente y es bastante fácil de aprender y usar. – srcspider

10

La estructura se ve bien para mí, pero hay algunos puntos:

  • que es normal para separar C++ archivos de cabecera y de origen en diferentes directorios, o tal vez hay una estructura en el directorio de módulos que no están mostrando ?
  • es probable que quieren directorios para poner archivos intermedios como * .obj en
  • se necesitarán diferentes directorios para depurar y liberar los archivos de salida
  • un directorio para los instaladores como InnoSetup y su instalación de archivos pueden ser útiles - usted tiene que tomar la decisión filosófica acerca de si el control de versiones éstos

en cuanto a herramientas para crear la estructura, en unos pocos minutos escribiendo un script bash es todo lo que necesita - vale la pena tener las mismas herramientas (como bash) disponible en todo plataformas.

+0

Gracias, agregué algunas de sus sugerencias al árbol. –

2

Recientemente publiqué question about packaging headers en un solo directorio, decidí ir con un pequeño número de directorios de inclusión.

¿Va a atender a Win64? Ese será un objetivo cada vez más importante.

Do no ponga sus archivos intermedios de compilación en cualquier lugar debajo de un árbol que se compruebe en svn. Si lo hace, dependiendo de sus herramientas de cliente svn, generarán mucho ruido como archivos que no están en el repositorio. Eso hace que sea difícil ver los archivos que ha agregado que debe estar en el repositorio.

En cambio, si su compilador lo permite, coloque los directorios intermedios a un lado.

De lo contrario, asegúrese de agregar todos los directorios intermedios a sus propiedades de exclusión de svn. Algunas GUI lo hacen más fácil que otros (Tortoise en Windows, Cornerstone o versiones en OS/X).

+0

No había pensado en win64 pero lo he agregado a la lista. ¡Gracias! svn facilita la exclusión de archivos intermedios, como .o y .obj, con un atributo svn-ignore en la carpeta contenedora. –

0

¿Puedo sugerir no utilizar la arquitectura para categorizar archivos de compilación?

Estaba tratando de aplicar la estructura de carpetas propuesta, pero no pude encontrar el lugar correcto para poner las definiciones comunes de archivos Makefile de Linux y los archivos de propiedades de Visual Studio. ¿Qué tal lo siguiente:

/project 
    /build 
     /linux 
     /macosx 
     /win32 (or win) 

Y ejemplo de caso incluiría:

/project 
    /build 
     /linux 
     Make.defs 
     Makefile [i386, amd64] 
     /win32 
     /VC8 
      /<project> 
       <project>.vcproj 
      <solution>.sln [Win32, x64] 
     /VC11 
      /<project> 
       <project>.vcxproj 
      <solution>.sln [Win32, x64, ARM] 

Si no desea definir la arquitectura construye a través de configuraciones, ¿qué otra capa carpeta bajo los tipos de plataforma?

/project 
    /build 
     /linux 
     /linux_amd64 
     /linux_i386 
     /macosx 
     /? 
     /win32 (or win) 
     /win32 
     /win64 

Si un determinado proyecto no tendrá ningún ficheros de construcción comunes para una plataforma, la estructura original sería suficiente.

Cuestiones relacionadas