Estoy a punto de abrir un proyecto C++ en Sourceforge. ¿Puedo obtener algunos consejos sobre la organización del código?

Question

Estoy a punto de subir un proyecto en el que he estado trabajando en Sourceforge bajo la GPL, y esperaba obtener algunos consejos sobre cómo organizar el código de una manera que sea fácil de entender y usar por cualquier desarrollador que pueda míralo, eso funciona bien con git, y la forma en que Sourceforge presenta las cosas.

Mis proyectos es un C aplicación multiplataforma ++, y consta de los siguientes:

• Una porción biblioteca, que hace el trabajo real
• Una porción GUI separada, que utiliza la porción biblioteca
• Bibliotecas de código abierto, cuyas rutas de acceso de inclusión son necesarias para compilar la biblioteca
• Bibliotecas de código abierto modificadas, que se han modificado y, por lo tanto, también forman parte directa de este proyecto
• Salida compilada de todas las bibliotecas

¿Cuál es la mejor manera de organizar esto?

Mientras se trabaja en él mismo, desde la raíz del proyecto lo tengo así:
/LibPortion
/GuiPortion
/libs/librerías de código abierto
bibliotecas /libs/código abierto modificado
/libs/compilado/para contener las bibliotecas compiladas, incluso al compilar para Windows algunas que no son de las bibliotecas de código abierto, como los archivos de la biblioteca Cygwin

¿Es esta una forma sensata de organizar las cosas? ¿Eso coincide con las convenciones y las expectativas?

Al registrar mi proyecto, ¿tiene sentido verificar las bibliotecas de código abierto y parte del proyecto? Me imagino que tiene sentido hacerlo, porque eso minimiza la fricción al configurar el proyecto y ejecutarlo para un nuevo desarrollador. Ciertamente, al menos debería verificar las bibliotecas de código abierto modificadas.

Además, ¿qué tiene sentido incluir en el repositorio en las bibliotecas compiladas? Estoy pensando que sería mejor decirle a git que ignore ese directorio y lo deje en blanco, ya que su contenido será diferente en cada objetivo de compilación, ya que mi proyecto es multiplataforma.

Sin embargo, también parece muy agradable para las personas que no quieren molestarse en crear y/o descargar todas las bibliotecas para ofrecer las bibliotecas pre compiladas para las principales plataformas. ¿Cuál es la forma más inteligente de compartirlos también? Estoy mirando Sourceforge, y no me resulta evidente cómo debería compartirlos si no fuera parte de mi repositorio de git.

Answer 1

En general, separe su trabajo del de terceros. En el nivel más básico, la carpeta raíz podría ser:

|- GUI 
|- Library 
|- Third-party 
    |- lib 
    |- source 

Aparté la carpeta de "terceros" en dos subcarpetas a los efectos del cumplimiento de licencias y facilidad de uso. Cómo distribuir exactamente las librerías de terceros dependerá completamente de sus licencias. Configure sus archivos make para que las librerías compiladas aterricen en la carpeta third-party\lib (que es donde también colocará las librerías compiladas previamente). De esta forma, el usuario puede descargar las librerías compiladas previamente e ignorar la carpeta source o descargar el código fuente e ignorar la carpeta lib dependiendo de si desean o no volver a compilar las librerías de terceros.

Si debe distribuir su versión modificada en formato binario y de código fuente, deberá alojar su versión modificada en su repositorio de origen (siempre que su elección sea una lib compilación previa).

Si está utilizando una biblioteca no modificada y está utilizando un repositorio de Subversion (o similar), puede usar la propiedad externals para vincular su repositorio al repositorio de la biblioteca de terceros de modo que cuando un usuario obtiene una copia de su fuente código, toma la fuente de la lib de su propio repositorio. De esta forma, no tiene que mantener un reflejo local de la fuente de la biblioteca. Dependiendo de lo que la lib de terceros tenga disponible en su repo, puede usar externos para vincular a una versión pre compilada de la lib de terceros también. Esto no solo disminuirá la cantidad de código que tendrá que alojar en su repositorio, sino que también indicará más claramente que la lib de terceros en particular no se ha modificado.

Al usar librerías no modificadas, sería aún mejor no incluir la fuente o el binario en su árbol fuente. Simplemente anote en su documentación que su proyecto depende de la biblioteca X (especifique también la versión, si es importante) y proporcione un enlace a la página de inicio/página de Sourceforge/repositorio de esa biblioteca. Deje que el desarrollador decida si desea compilar la biblioteca, descargar una versión compilada previamente o posiblemente usar la versión que ya tiene instalada. Esto significa que tampoco puede suponer que la biblioteca o sus encabezados existirán en un directorio particular relativo a su código fuente; en su lugar, tendrá que confiar en que el usuario instale las bibliotecas donde el compilador pueda encontrarlas. Su código simplemente asumirá que están en la ruta de búsqueda del compilador.

También es posible que sus bibliotecas modificadas se implementen de modo que una propiedad externa haga que la fuente no modificada se recupere del repositorio de terceros, y su sistema de compilación puede aplicar un parche que contenga sus modificaciones. De esta forma, no estaría técnicamente distribuyendo código modificado, lo que podría significar varios términos de licencia menos que debe cumplir.

Normalmente, no recomendaría distribuir versiones precompiladas de su biblioteca dentro de su repositorio de origen. Con Sourceforge, puede precompilar su biblioteca (o cualquier otro "producto final") para las principales plataformas y ofrecerlas como descargas.

Answer 2

Si yo fuera usted, primero separaría el proyecto entre su propio código y las bibliotecas de terceros. El siguiente árbol podría funcionar:

/ 
|- GUI 
|- lib 
|- third parties 
    |- compiled targets 
    |- "your first library" 
    |- "another library" 
    |- ... 

No debería ser la sede bibliotecas compilado en su repositorio en mi humilde opinión. Es más flexible permitir que los desarrolladores los compilen en su propia computadora, pero si desea tener un tarball entregable, debe incluir bibliotecas precompiladas.

Answer 3

/
|- bin - Compiled binaries go here (not submitted to source-control) 
|- build - buildscripts, tools used to build your code. 
|- lib - Compiled libraries go here (not submitted to source-control) 
|- local - (not submitted to source control) 
    |- obj - Compiled object-files (not submitted to source-control) 
    |- msvc - Autogenerated solution files for visual studio (not submitted to source control) (if applicable) 
    |- scripts - Autogenerated script files (if applicable) 
|- units 
    |- libportion 
     |- include - external headers for other units to see 
     |- src 
    |- guiportion 
     |- include 
     |- src 
|- external 
    |- externallib1 
     |- include 
     |- src 

build - simplified build-script calling the correct convention to your buildscripts. 
README - text-file explaining your software and the layout of your source. 

Esta es la organización que he estado usando últimamente y ha sido muy apreciada por todos los que están incluidos. También hace que sea fácil separar las bibliotecas entre sí y facilitar la entrega de encabezados internos y encabezados externos en las bibliotecas.

Editar: Se agregó el directorio "local".

Answer 4

En mi humilde opinión, la organización de varios proyectos de código abierto podría ayudar.

vlc project page puede ser una buena referencia