Usando Make – escribir menos Makefile

Artículo original ↗ Discusión en Hacker News ↗

Los programadores vuelven al venerable sistema de construcción `make`, observando hasta dónde se pueden estirar sus reglas implícitas y sus Makefiles mínimos, desde pequeños proyectos en C hasta la orquestación de contenedores y la gestión de dotfiles. Muchos elogian `make` por su ubicuidad, su seguimiento simple de dependencias y su capacidad para servir de front-end a herramientas más nuevas como CMake o Ninja, mientras que otros sostienen que su sintaxis arcana, sus reglas ocultas y sus problemas de escala hacen que generadores modernos o ejecutores de tareas (por ejemplo, CMake, Meson, Ninja, just, Task) sean más productivos. Junto con el debate sobre sistemas de construcción, quienes comentan critican brevemente el diseño del artículo al estilo manpage por su mala legibilidad y accesibilidad, especialmente en móvil o con zoom.

Presentación al estilo manpage y legibilidad

  • A varios lectores les gusta la estética retro de “manpage”; otros la encuentran difícil de leer, especialmente en teléfonos o con mucho zoom.
  • Las quejas se centran en el texto de ancho fijo que no se refluye y en los tamaños de fuente pequeños; algunos señalan que esto es irónico porque las man pages reales se reajustan al ancho de la terminal.
  • Se plantean preocupaciones de accesibilidad (problemas de visión, lectores de pantalla). Otros argumentan que un sitio personal puede priorizar el estilo sobre la función.

Uso mínimo de make y reglas implícitas

  • Quienes comentan destacan que muchos ejemplos del artículo pueden simplificarse aún más apoyándose en reglas integradas:
    • Si existe foo.c, make foo funciona sin un Makefile.
    • Una regla de enlace como foo: foo.o bar.o baz.o a menudo puede omitir el comando explícito del compilador y usar solo LDFLAGS/LDLIBS.
  • Se recomiendan las variables automáticas ($@, $^, $<) para evitar repetir listas de archivos, aunque a algunos les disgustan los símbolos “mágicos” por legibilidad.

Globbing, listas de objetos y Makefiles genéricos

  • Un grupo aboga por wildcard/globbing para descubrir fuentes y evitar listar archivos manualmente, además de permitir Makefiles genéricos reutilizables en muchos proyectos y plataformas.
  • Otros advierten que el globbing:
    • Es más difícil de razonar (coincidencias no deseadas, problemas de seguridad/confiabilidad).
    • Puede ser lento en árboles muy grandes o al hacer escaneos recursivos.
    • Es problemático para flags de granularidad fina y para mapear árboles de código ordenados a directorios de compilación fuera del árbol.
  • Se hace referencia a patrones multiarquitectura ya establecidos donde se prefieren rutas explícitas por claridad y control.

Make frente a CMake, Meson, Ninja, Autotools, scripts

  • Hay un fuerte desacuerdo sobre “make en 2023”:
    • Los críticos lo califican de arcaico, verboso y frágil más allá de proyectos pequeños; prefieren CMake/Meson o compilaciones hechas a mano en Python/Node, citando mejor ergonomía, descubrimiento de dependencias e integración con IDE.
    • Los defensores destacan la ubicuidad de make, su huella mínima de dependencias (buena para sistemas de arranque), su portabilidad y décadas de estabilidad.
  • Se reconoce que Ninja es más rápido en compilaciones enormes al eliminar funciones costosas de make, pero algunos sostienen que la sobrecarga de parseo es insignificante para proyectos típicos.
  • Se menciona Autotools como potente pero pesado; CMake se ve como el generador multiplataforma de facto, pese a su propia complejidad y el dolor al depurarlo.
  • Algunos sugieren que las herramientas modernas simplemente vuelven a aprender las lecciones de make, acumulando lentamente una complejidad similar.

Make como ejecutor de tareas / front-end del proyecto

  • Muchos usan make principalmente como punto de entrada uniforme y ejecutor de tareas:
    • Objetivos como make, make test, make install, make clean, make dev.
    • A menudo solo llaman por debajo a CMake, Cargo, Docker o herramientas específicas del lenguaje.
  • Otros argumentan que el uso intensivo de objetivos .PHONY es una señal de alerta y recomiendan herramientas como just o task para la orquestación pura de comandos.

Ergonomía, defectos y límites de uso

  • Quejas comunes: sintaxis sensible a tabulaciones, reglas implícitas, rarezas con espacios en blanco, manejo incómodo de rutas con espacios y dificultad para mantener Makefiles grandes.
  • Mitigaciones sugeridas: mantener pequeños los Makefiles individuales, centralizar la lógica de plataforma en plantillas, generar dependencias automáticamente y usar -j / -l para compilaciones en paralelo.
  • Consenso amplio: make es excelente para compilaciones orientadas a archivos pequeñas o medianas y como pegamento; para sistemas grandes y multiplataforma, a menudo se vuelve doloroso y frecuentemente se envuelve o se reemplaza.