gestión de la dependencia en el proyecto c

déjame describir la situación primero y luego haré mi pregunta.

Tengo un module A genérico. Consiste en un file c y un file h. La única dependencia que tiene es en el file stdint.h.

También hay un module B que usa el module A (#include "module_A.h"). Hay otro module C que también usa el module A. Ambos modules B y C tienen dependencia del module A "administrado" a través de la propiedad svn: externals para asegurarse de que cualquiera que use el module B o C también haya desprotegido el module A.

Los modules B y C no tienen relación entre sí. Durante el desarrollo de algún proyecto sucedió que ambos modules B y C eran necesarios. Svn: las properties externas se han establecido en el proyecto para get esos modules en los directorys del proyecto. Y ahora tenemos en la estructura del directory del proyecto algo así:

src/module_B/module_B.c src/module_B/module_B.h src/module_B/module_A/module_A.c src/module_B/module_A/module_A.h src/module_C/module_C.c src/module_C/module_C.h src/module_C/module_A/module_A.c src/module_C/module_A/module_A.h 

El comstackdor detecta definiciones duplicadas de funciones y detiene la compilation con errores.

Usamos Eclipse para desarrollar.

Pregunta 1. ¿Cómo resolver tal problema?

Pregunta 2. Si profundizamos en este tema, podemos imaginar una situación en la que el module A tiene varias revisiones y los modules B y C señalan diferentes revisiones del module A. ¿Cómo resolver dicho problema?

Q1:

Su linker se volverá loco, si hay múltiples definiciones de la misma function. Debes asegurarte de que solo tienes 1 versión de A en el proyecto:

 src/module_A/module_A.c src/module_A/module_A.h src/module_B/module_B.c src/module_B/module_B.h src/module_C/module_C.c src/module_C/module_C.h 

Q2:

La única manera de hacer que esto funcione es actualizar B y C para que sean compatibles con la misma versión de A.

Su file de encabezado para A debería tener probablemente información de número de versión, que indicaría compatibilidad de versión:

 // Version 1.2 #define MODULE_A_VER_MAJOR 1 /* For backwards incompatible changes */ #define MODULE_A_VER_MINOR 2 /* For bug fixes */ 

Luego, puede agregar comprobaciones de time de compilation a los modules B y C para asegurarse de que no se comstackn accidentalmente con la versión incorrecta de A.

 #include "module_A.h" // Require at least 1.1 #if MODULE_A_VER_MAJOR != 1 || MODULE_A_VER_MINOR < 1 #error Invalid A version! #endif 

El comstackdor detecta definiciones duplicadas de funciones y detiene la compilation con errores.

Tales errores siempre aparecen debido a errores de progtwigción. Utilice protectores de encabezado y nunca asigne ningún object en un file H.

Si profundizamos en este tema, podemos imaginar una situación en la que el module A tiene varias revisiones y los modules B y C apuntan a diferentes revisiones del module A. ¿Cómo resolver dicho problema?

El escenario no tiene ningún sentido. Hay dos casos:

  • Si ambos dependen de A y solo existen en el mismo proyecto, entonces tendrán que actualizar B y C cada vez que A se actualice.

  • De lo contrario, si existen en varios proyectos, entonces para que esta discusión tenga algún sentido, debe haber un repository "global" que no sea específico del proyecto, donde almacena la versión más reciente de cada file. Es decir, su colección de files para ser reutilizados en varios proyectos. En este repository, todos los files deben estar actualizados.

    Digamos que actualiza A y C, pero por alguna razón no B. Eso solo puede significar que B es específico del proyecto; de lo contrario, debe actualizarlo junto con A. Si es específico del proyecto, entonces no pertenece a el repository "global", sino más bien uno específico del proyecto. Y eso soluciona todo, ya que en el repository específico del proyecto, puede mantener una versión anterior de A.