O sucesso e o fracasso do Ninja (2020)

• Sucesso e fracasso do Ninja

  • Cerca de 9 anos atrás, o autor lançou o Ninja, um sistema de build semelhante ao Make. No início, sentia vergonha dele, mas hoje ele é amplamente usado.
  • Entre os principais projetos que usam o Ninja estão Chrome, Android e o projeto Meson.
  • O Ninja é o projeto open source de maior sucesso do autor; foi lançado em 2011, teve sua propriedade transferida em 2014 e hoje está com o terceiro mantenedor.
  • O autor aprendeu que, em programação, a arquitetura é mais importante do que escrever código, e que questões sociais são ainda mais importantes do que a arquitetura.

• Detalhes técnicos

  • O Ninja é um sistema simples que executa comandos de acordo com os requisitos fornecidos.
  • O Ninja recebe arquivos ninja.build, verifica os tempos de modificação dos arquivos e executa em paralelo os comandos necessários.
  • Em comparação com o Make, o Ninja tem menos recursos na linguagem de build de entrada e prioriza a execução rápida.
  • O Ninja mapeia caminhos de arquivos para objetos em memória, otimizando a comparação de caminhos.

• Notas de arquitetura

  • A representação de grafo do Ninja usa um grafo bipartido entre arquivos e comandos para capturar melhor a estrutura do build.
  • Ele usa dados adicionais de dependência para lidar com dependências de headers em C.
  • O Ninja não é um processo daemon persistente; a cada execução, ele trabalha do zero.
  • O estado dos arquivos já é armazenado em cache pelo kernel, então quase não há necessidade de armazená-lo em cache novamente no espaço do usuário.
  • O Ninja foi projetado com base no build do Chrome e enfrenta problemas de escalabilidade em projetos de grande porte.

• A metáfora do 'assembler'

  • O Ninja não implementa os recursos de vários sistemas de build; ele implementa apenas o grafo de ações, permitindo que o usuário escolha outros programas geradores.
  • Esse design torna o Ninja rápido e flexível.

• A importância dos padrões

  • Por padrão, o Ninja executa comandos em paralelo, o que permite builds paralelos mais seguros do que no Make.

• Velocidade

  • O Ninja foi focado no desempenho de builds incrementais em codebases grandes, o que tem grande impacto na satisfação dos usuários.
  • O Ninja usa menos CPU, melhorando também o desempenho geral do build.

• CMake

  • O Ninja se integrou bem ao CMake, e essa integração passou a ser usada em trabalhos com LLVM.

• Suporte ao Windows

  • O Ninja também funciona no Windows, e muitos dos primeiros usuários eram usuários de Windows.

• Trabalhos relacionados

  • O design do Ninja foi inspirado no blaze/bazel, o sistema de build do Google.

• Manutenção de open source

  • Manter projetos open source não é divertido, e houve muitas exigências e críticas por parte dos usuários.
  • O autor queria impressionar outros hackers por meio do software.

• Agradecimento final

  • O autor agradece aos mantenedores e contribuidores do Ninja.

[GN⁺]

Comentários do Hacker News

• Há a opinião de que, em programação, a arquitetura é mais importante do que escrever código, e que questões sociais são ainda mais importantes do que a arquitetura

  • Dizem que isso expressa muito bem uma ideia que carregavam há muito tempo

• O Ninja tem um papel importante no sistema de build do Android

  • No início usavam makefiles, mas ficou mais complexo com um sistema de build declarativo personalizado chamado soong
  • O Google desenvolveu o kati, que converte Makefiles em arquivos de build do Ninja
  • A transição para o Ninja leva tempo, mas depois da migração ele funciona rapidamente

• Há quem diga que o Google realizou pesquisas sobre latência e que gostariam que esse estudo fosse tornado público

• Há a opinião de que, ao usar CMake, como o Ninja é necessário para módulos de C++20, ele continuará sendo usado por um bom tempo

• Migraram do Ninja para o Samurai e dizem que houve melhorias em todos os aspectos

  • Acham que um sistema de build precisa calcular o hash de todas as entradas e verificar se elas existem no registro

• Há a opinião de que é necessário fazer concessões entre precisão, conveniência e desempenho, e que isso deve ser escolhido de forma intencional

  • Dizem que uma ferramenta que abre mão de precisão em favor da conveniência pode criar um ecossistema mais preciso

• Têm experiência com sistemas de build e dizem que o Ninja é pequeno o suficiente para ser implementado na linguagem de programação favorita de alguém

  • Perguntam se existe um tutorial passo a passo para criar o próprio sistema de build

• Acham que o nome Ninja é bom e dizem que há maneiras de torná-lo mais rápido

  • Explicam que a ferramenta intencionalmente não mantém o estado da execução anterior