¿Cuál es la mejor manera de organizar mi código de proyecto C y sus bibliotecas externas?

Question

Estoy comenzando un nuevo proyecto C, que está basado principalmente en OSS. También estará en SourceForge, y me gustaría aprovechar esta oportunidad para aprender las mejores prácticas establecidas para organizar este tipo de código. Estoy usando librerías como libcurl y libz, y las compilaré usando MinGW y MSYS.

Estaré distribuyendo copias de la fuente de todas las bibliotecas que estoy utilizando con mi proyecto, por lo que las personas que descarguen la fuente no tendrán que ir a buscar y buscar dependencias. ¿A qué debo llamar el directorio donde guardo las bibliotecas? Hasta ahora, dudo entre:

• lib, porque son bibliotecas. Sin embargo, 'lib' tiene una connotación diferente en UNIX-world.
• src, porque son archivos de origen.
• 3er partido, porque no lo escribí.

¿Y dónde debería compilar estas bibliotecas? ¿Debería simplemente configurarlos e instalarlos en la raíz del sistema, o debería configurar un directorio donde todas las bibliotecas deberían compilar y vincular desde allí? Obviamente, esto tendrá ramificaciones para mi Makefile.

¿Cómo debo hacer esto? ¿Existen convenciones establecidas que debo seguir? ¿Están escritos en alguna parte?

Answer 1

Primero, para bibliotecas externas usaría vendor, pero eso es solo una preferencia.

En segundo lugar, no creo que sea una buena idea instalar otras bibliotecas en una raíz del sistema, sin el conocimiento del usuario. Lo más importante es que esto entrará en conflicto con las versiones instaladas posteriores de esas bibliotecas. Por lo tanto, creo que el mejor lugar para estas bibliotecas sería en el mismo directorio que su aplicación.

También puede compilar estáticamente estas bibliotecas en su programa.

Answer 2

En un trabajo anterior, el estándar consistía en instalarlos en un directorio llamado 3rdparty y crear las bibliotecas allí mismo (en 3rdparty/LIBNAME/Debug, etc.).

Answer 3

Usamos algo con el sufijo _ext o _EXT (es decir, MyProject_EXT) para indicar que es externo a nuestro proyecto almacenar el código fuente de los paquetes externos que vinculamos.

Estoy de acuerdo con Peter. Las bibliotecas externas no deberían estar integradas en la raíz del sistema ya que pueden causar conflictos. Los construiría en su directorio y luego los instalaría en un directorio/lib (o tal vez/extlib) que es exclusivo de su aplicación y los enlazaría allí.

Answer 4

Por favor no envíe envíe fuentes de terceros con su código, ya sea en la fuente o vinculadas estáticamente en los binarios, o de cualquier otra manera. Eso solo interferirá con otras copias del mismo, y no se actualizará cuando la biblioteca requiera reparación. ¡Dígale al usuario cuáles son los requisitos (y manténgase al día con los cambios de API en la biblioteca!). Un usuario que se auto compilará se asegurará de obtener las dependencias, una distribución se asegurará de que su paquete funcione con la versión que envían.