Muy buenas Rani,
paso a reflejar algunos casos de uso que estuve probando.
Casos de #includes
Abstrayéndome de si existe sentido en hacerlo, probé los 4 casos:
- SharedLib1 incluye a SharedLib2
- SharedLib incluye a StaticLib
- StaticLib incluye a SharedLib
- StaticLib1 incluye a StaticLib2
Todos fueron exitosos, salvo para el caso 2. Los logs que me dieron (luego de haber hecho el clean):
$ make
make -C utils
make[1]: se entra en el directorio '/home/user/Documentos/template-tests/utils'
../compilation.mk:43: el objetivo 'obj/' se proporcionó más de una vez en la misma regla
../compilation.mk:43: el objetivo 'obj/' se proporcionó más de una vez en la misma regla
../compilation.mk:43: el objetivo 'obj/' se proporcionó más de una vez en la misma regla
../compilation.mk:43: el objetivo 'obj/' se proporcionó más de una vez en la misma regla
mkdir -pv obj/
mkdir: se ha creado el directorio 'obj/'
gcc -g -Wall -DDEBUG -c -o "obj/stream.o" src/stream.c -I./include
gcc -g -Wall -DDEBUG -c -o "obj/module_config.o" src/module_config.c -I./include
gcc -g -Wall -DDEBUG -c -o "obj/connections.o" src/connections.c -I./include
gcc -g -Wall -DDEBUG -c -o "obj/common_utils.o" src/common_utils.c -I./include
gcc -g -Wall -DDEBUG -c -o "obj/buffer.o" src/buffer.c -I./include
mkdir -pv bin/
mkdir: se ha creado el directorio 'bin/'
ar rcs -o "bin/libutils.a" obj/stream.o obj/module_config.o obj/connections.o obj/common_utils.o obj/buffer.o
make[1]: se sale del directorio '/home/user/Documentos/template-tests/utils'
make -C matelib
make[1]: se entra en el directorio '/home/user/Documentos/template-tests/matelib'
mkdir -pv obj/
mkdir: se ha creado el directorio 'obj/'
gcc -g -Wall -DDEBUG -fPIC -c -o "obj/matelib.o" src/matelib.c -I../utils/include -I./include
mkdir -pv bin/
mkdir: se ha creado el directorio 'bin/'
gcc -g -Wall -DDEBUG -shared -o "bin/libmatelib.so" obj/matelib.o -L../utils/bin -lutils -lcommons
/usr/bin/ld: ../utils/bin/libutils.a(connections.o): warning: relocation against `stderr@@GLIBC_2.2.5' in read-only section `.text'
/usr/bin/ld: ../utils/bin/libutils.a(connections.o): relocation R_X86_64_PC32 against símbolo `stderr@@GLIBC_2.2.5' can not be used when making un objeto compartido; recompile con -fPIC
/usr/bin/ld: falló el enlace final: bad value
collect2: error: ld devolvió el estado de salida 1
make[1]: *** [../compilation.mk:38: bin/libmatelib.so] Error 1
make[1]: se sale del directorio '/home/user/Documentos/template-tests/matelib'
make: *** [makefile:11: matelib] Error 2
Casos de módulos de test (en CUnit)
Probé los 2 casos como lo recomendaba la guía. El makefile del módulo de tests se encuentra coherente para la "opción 2: en una carpeta aparte del repo", pero no para la opción 1. Para la opción 1 tuve que modificar el makefile del módulo de tests:
# Original
...
################################################################################
include ../compilation.mk
################################################################################
include ../execution.mk
# Adaptado para la Opción 1
...
################################################################################
include ../../compilation.mk
################################################################################
include ../../execution.mk
Probé también en hacer un módulo de test exclusivamente para la shared lib y funcionó (para ambas opciones). La posibilidad de hacer esto no se encuentra explícito en la guía.
Declaraciones globales
Tuve casos en donde las declaraciones globales, en el archivo excluído por:
# Excluded source files (eg: main() function)
EXCLUDE=main.c
deben ser declaradas en sus archivos de test, ya que de lo contrario no los reconoce:
/home/user/Documentos/template-tests/kernel/tests/../src/scheduler.c:51: referencia a `kernelLogger' sin definir
Este aspecto no se encuentra reflejado en la guía.
Saludos Rani 😄
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent