¿Cómo manejar un conflicto de dependencia transitiva usando submódulos Git y CMake?
Tenemos varios repositorios de Git, algunos con nuestro propio código y otros con un código de biblioteca de terceros ligeramente modificado. Un gráfico de dependencia simplificado se ve así:
executable_A
| |
| v
| library_B
| |
v v
library_C
Entonces el ejecutable tiene dos dependencias delibrary_C
, uno directo y uno transitivo. Espero unir todo esto usando submódulos Git y CMake, por lo que una estructura de directorio simplificada se ve así:
executable_A/
CMakeListst.txt
library_B/
CMakeLists.txt
library_C/
CMakeLists.txt
library_C/
CMakeLists.txt
Como puede ver, ellibrary_C
El repositorio se incluye como submódulo dos veces. Supongamos que ambos submódulos apuntan a la misma confirmación (cualquier idea sobre cómo aplicar eso sería bienvenida, pero no es el tema de esta pregunta).
Estamos usandoadd_subdirectory
, target_link_libraries
ytarget_include_directories
para gestionar estas interdependencias. Bastante estándar
El problema es que a CMake no le gusta si crea un objetivo con el mismo nombre dos veces, por lo que se queja:
Error de CMake en library_C / CMakeLists.txt: 13 (add_library):
add_library no puede crear el objetivo "library_C" porque ya existe otro objetivo con el mismo nombre. El objetivo existente es una biblioteca estática creada en el directorio fuente "... / library_B / library_C".
Consulte la documentación de la política CMP0002 para obtener más detalles.
Prefiero no eliminar la dependencia directa deexecutable_A
enlibrary_C
, porque el hecho de que se extrae a través delibrary_B
es un detalle de implementación delibrary_B
eso no debe ser confiado. Además, este enfoque se romperá tan pronto como agreguemos otra dependencia comoexecutable_A --> library_D --> library_C
.
(Esta pregunta es lo más cercano que pude encontrar, pero es un poco más general y de todos modos permanece sin respuesta).