Usando Make – escrevendo menos Makefile

Apresentação em estilo manpage e legibilidade

• Vários leitores gostam da estética retrô de “manpage”; outros acham difícil de ler, especialmente em celulares ou com alto zoom.
• As reclamações se concentram em texto de largura fixa, sem reflow, e em tamanhos de fonte pequenos; alguns observam que isso é irônico porque páginas de manual reais se ajustam à largura do terminal.
• Surgem preocupações de acessibilidade (problemas de visão, leitores de tela). Outros argumentam que um site pessoal pode priorizar estilo em vez de função.

Uso mínimo de make e regras implícitas

• Comentadores destacam que muitos exemplos do artigo podem ser ainda mais simplificados ao depender de regras internas:
  • Se foo.c existir, make foo funciona sem um Makefile.
  • Uma regra de link como foo: foo.o bar.o baz.o muitas vezes pode omitir o comando explícito do compilador e usar apenas LDFLAGS/LDLIBS.
• Variáveis automáticas ($@, $^, $<) são recomendadas para evitar repetir listas de arquivos, embora alguns não gostem dos símbolos “mágicos” por motivos de legibilidade.

Globbing, listas de objetos e Makefiles genéricos

• Um grupo defende wildcard/globbing para descobrir fontes, para nunca listar arquivos manualmente e para permitir Makefiles genéricos reutilizados em muitos projetos e plataformas.
• Outros alertam que globbing é:
  • Mais difícil de raciocinar (correspondências indesejadas, problemas de segurança/confiabilidade).
  • Potencialmente lento em árvores muito grandes ou ao fazer varreduras recursivas.
  • Problemático para flags granulares e para mapear árvores de fontes organizadas para diretórios de build fora da árvore.
• Há referência a padrões consolidados multi-arquitetura em que caminhos explícitos são preferidos por clareza e controle.

Make vs CMake, Meson, Ninja, Autotools, scripts

• Há forte discordância sobre “make em 2023”:
  • Críticos o chamam de arcaico, verboso e frágil além de projetos pequenos; preferem CMake/Meson ou builds feitos à mão em Python/Node, citando melhor ergonomia, descoberta de dependências e integração com IDE.
  • Defensores destacam a onipresença do make, a pequena pegada de dependências (boa para sistemas de bootstrap), a portabilidade e décadas de estabilidade.
• Ninja é reconhecido como mais rápido em builds enormes por abrir mão de recursos caros do make, mas alguns argumentam que a sobrecarga de parsing é insignificante para projetos típicos.
• Autotools é mencionado como poderoso, porém pesado; CMake é visto como o gerador multiplataforma de facto, apesar de sua própria complexidade e da dificuldade de depuração.
• Alguns sugerem que as ferramentas modernas apenas reaprendem as lições do make, acumulando lentamente complexidade semelhante.

Make como executor de tarefas / front-end de projeto

• Muitos usam make principalmente como ponto de entrada uniforme e executor de tarefas:
  • Alvos como make, make test, make install, make clean, make dev.
  • Muitas vezes apenas chamam CMake, Cargo, Docker ou ferramentas específicas da linguagem por baixo.
• Outros argumentam que o uso pesado de alvos .PHONY é um sinal ruim e recomendam ferramentas como just ou task para orquestração pura de comandos.

Ergonomia, arestas e limites de uso

• Queixas comuns: sintaxe sensível a tabs, regras implícitas, peculiaridades com espaços em branco, tratamento estranho de caminhos com espaços e dificuldade de manter Makefiles grandes.
• Mitigações sugeridas: manter cada Makefile pequeno, centralizar a lógica de plataforma em templates, gerar dependências automaticamente e usar -j / -l para builds paralelos.
• Consenso amplo: make é excelente para builds pequenos a médios, orientados a arquivos, e como cola; para sistemas grandes e multiplataforma, muitas vezes se torna doloroso e frequentemente é encapsulado ou substituído.