Dependencias de cabeceras

Tu Makefile declara que un objeto depende de su fuente. La verdad es que depende de su fuente y de la clausura transitiva de todo lo que esa fuente incluye, directa o indirectamente. Esa diferencia entre el grafo declarado y el grafo real es el fallo más caro de los sistemas de construcción escritos a mano, porque no produce un error: produce un binario que enlaza limpio, arranca bien y corrompe memoria por razones que ninguna herramienta de depuración va a explicarte.

El fallo que no avisa

El escenario es siempre el mismo. Una cabecera declara una estructura; dos unidades de traducción la incluyen. Se modifica la estructura y solo una de las dos unidades se recompila, porque el Makefile no sabía que la otra dependía de esa cabecera.

struct Config {
    int  puerto;
    char nombre[32];   /* ayer eran 16 */
};

El objeto que no se recompiló conserva el sizeof antiguo, los desplazamientos antiguos de cada campo y el código de acceso antiguo. El enlazador acepta la unión sin una sola queja, porque los tipos de C no viajan en la tabla de símbolos: solo viajan nombres. El programa arranca, escribe treinta y dos bytes donde el otro módulo reservó dieciséis y corrompe lo que hubiera al lado.

Este es el modo de fallo canónico de la compilación separada, y tiene tres agravantes. Es silencioso, porque no hay diagnóstico en ninguna fase. Es no determinista, porque el efecto depende de qué haya en memoria contigua. Y es no reproducible, porque un make clean lo hace desaparecer, con lo que el desarrollador concluye que fue cosa del compilador y sigue adelante.

El compilador ya lo sabe

El preprocesador conoce con exactitud la lista de ficheros que abrió al procesar una unidad de traducción, porque los abrió él. Basta con pedirle que la escriba. La bandera -MMD hace exactamente eso durante la compilación real, sin coste apreciable y sin un segundo paso.

gcc -std=c23 -MMD -MP -c src/main.c -o build/main.o
cat build/main.d

build/main.o: src/main.c src/config.h src/parser.h src/util.h

src/config.h:
src/parser.h:
src/util.h:

Lo generado es un fragmento de Makefile perfectamente válido: una regla sin receta cuya única función es añadir aristas al grafo. Make combina las reglas que comparten objetivo, así que estos prerrequisitos se suman a los que ya declaraste.

Las banderas de la familia forman una pequeña taxonomía que conviene tener clara.

La elección estándar es -MMD -MP. Se omiten las cabeceras del sistema porque cambian solo al actualizar el sistema operativo, momento en el que reconstruir todo es lo correcto de todos modos, y porque incluirlas multiplica el tamaño de los ficheros generados.

Hay dos banderas vecinas que no participan en el grafo pero conviene conocer. La primera es -H, que imprime el árbol de inclusiones con la profundidad marcada y sirve para diagnosticar por qué una unidad tarda diez segundos en preprocesarse. La segunda es -MJ, que emite un fragmento de base de datos de compilación, el fichero que los servidores de lenguaje leen para saber con qué banderas se compila cada unidad.

gcc -std=c23 -H -c src/main.c -o /dev/null 2>&1 | head -30
gcc -std=c23 -MJ build/main.json -c src/main.c -o build/main.o

El coste real de una cabecera no es el fichero que ves sino su clausura. Incluir una cabecera de conveniencia que arrastra otras treinta multiplica el trabajo del preprocesador en cada unidad y, sobre todo, amplía el conjunto de objetos que una sola edición invalida. Un grafo de dependencias correcto hace visible ese coste, que antes estaba oculto precisamente porque nadie recompilaba lo que debía.

-MT importa cuando el objeto no vive junto a la fuente: sin él, el objetivo generado sería el nombre simple del objeto y no la ruta dentro del directorio de construcción, con lo que la regla no casaría con nada y el fichero sería inerte.

Cerrar el ciclo

Falta el último paso: que Make lea esos ficheros. Se hace con -include, la variante que no falla si el fichero todavía no existe, algo imprescindible en la primera compilación.

CC     := gcc
CFLAGS := -std=c23 -Wall -Wextra -Og -g3
DEPFLAGS = -MMD -MP -MF build/$*.d -MT $@

SRC := $(shell find src -name '*.c')
OBJ := $(patsubst src/%.c,build/%.o,$(SRC))
DEP := $(OBJ:.o=.d)

build/prog: $(OBJ)
	@mkdir -p $(@D)
	$(CC) $(CFLAGS) $^ -o $@

build/%.o: src/%.c
	@mkdir -p $(@D)
	$(CC) $(CFLAGS) $(DEPFLAGS) -c $< -o $@

-include $(DEP)

El mecanismo tiene una elegancia recursiva que merece la pena entender. Make lee los ficheros incluidos al arrancar y comprueba si él mismo sabe reconstruirlos. Si un fichero de dependencias falta, se genera al compilar el objeto correspondiente; si existe pero está desfasado, se regenera en la misma compilación que actualiza el objeto. El grafo se mantiene a sí mismo.

flowchart TD
A[make arranca] --> B[lee los ficheros .d existentes]
B --> C[anade aristas al grafo]
C --> D[compara marcas de tiempo]
D --> E[compila lo obsoleto]
E --> F[cada compilacion reescribe su .d]
F -.siguiente invocacion.-> B
style C fill:#89b4fa,color:#11111b
style F fill:#a6e3a1,color:#11111b

-MP resuelve un problema concreto y muy real. Si borras o renombras una cabecera, el fichero de dependencias viejo sigue nombrándola como prerrequisito y Make aborta con no rule to make target, dejando el proyecto en un estado en el que solo make clean avanza. Los objetivos vacíos que -MP genera hacen que una cabecera desaparecida se considere trivialmente construible, con lo que Make recompila el objeto, se regenera el fichero de dependencias correcto y el problema se disuelve solo.

Lo que el método no cubre

El primero se resuelve con la misma idea llevada un paso más allá: escribir las banderas en un fichero, hacer que ese fichero solo se reescriba cuando su contenido cambie y declararlo prerrequisito de todos los objetos. El segundo exige prerrequisitos de orden, la construcción que obliga a producir algo antes que otra cosa sin forzar reconstrucción cuando cambia. El tercero no tiene solución dentro de Make y es una de las razones de peso para usar un generador de nivel superior.