Ninja: Suporte a definição de verbosidade por meio do ambiente

Acho que em casos como esse você pode fazer um script de shell para obedecer às variáveis ​​de ambiente. Caso contrário, posso pensar em ambientes equivalentes onde alguém deseja VERBOSE = 1 para controlar a verbosidade de um programa diferente do Ninja.

Acho que em casos como esse você pode fazer um script de shell para obedecer às variáveis ​​de ambiente.

Essas variáveis ​​de ambiente são para ninja, então como elas seriam obedecidas se o ninja não as reconhecesse?

Além disso, nem sempre é viável ou razoável modificar a linha de comando das ferramentas em scripts, pois pode haver um grande número. O que você está sugerindo é que cada script adote uma maneira única de ajustar os sinalizadores passados ​​para o comando, o que também não é razoável.

Eu li os outros PRs e questões associadas a esta situação e não achei nenhuma das respostas muito bem pensada. Em cada caso, é simplesmente assumido que o usuário tem controle direto sobre onde e como ninja é executado ou está mesmo em posição de fazer qualquer coisa de forma realista, especialmente quando os sistemas de configuração geram ninja.build scripts como parte do pipeline.

Essas variáveis ​​de ambiente são para ninja, então como elas seriam obedecidas se o ninja não as reconhecesse?

O script iria reconhecê-los e passar, por exemplo, -v para o ninja.

Como eu previ, você espera que cada script, ou mesmo algo semelhante a um script, codifique seu próprio conjunto de lógica para passar opções para o ninja. Isso não é nada razoável.

Não, você só precisa de um script para fazer isso, que você nomeia ninja e coloca em seu PATH antes do ninja real executável.

Achei que isso já tivesse sido abordado em vários outros relatórios de problemas. Isso também não é razoável, pois agora começa a afetar os pipelines de compilação de reprodutibilidade onde os ambientes são viáveis. Também pressupõe que as pessoas tenham a capacidade de fazer o que você está sugerindo (pense em segurança PATH ).

Isso também não é razoável, pois agora começa a afetar os pipelines de compilação de reprodutibilidade onde os ambientes são viáveis.

Você teria seu script sempre lá, então você pode rastrear VERBOSE da mesma forma que faria se o próprio ninja tomasse conta dele.

pense seguro PATH

O que você quer dizer com isso?

Não estou interessado em VERBOSE , acho que as outras sugestões de expor os sinalizadores por meio de NINJAFLAGS são mais apropriadas, conforme sugerido em muitas outras edições sobre este tópico.

Novamente, esta é uma solicitação irracional quando você gerencia centenas de pacotes, alguns dos quais usam cmake para gerar scripts de compilação ninja. A criação de um invólucro desnecessário para atuar como dependência é excessivamente envolvida quando sistemas tradicionais como make (com Makefile s gerados ou escritos de maneira apropriada) continuam a honrar não apenas os ambientes de fato, como CFLAGS , CXXFLAGS , LDFLAGS , etc. mas também MAKEFLAGS onde muitos de nós definiríamos algo no sentido de -j$(nproc) .

Isso novamente nos leva à noção de um caminho seguro; sistemas como scripts sudo e build / CI definirão PATH como um bom padrão conhecido para evitar qualquer poluição potencial da construção, geralmente também sustentada por um chroot limpo.

alguns dos quais usam cmake para gerar scripts de compilação ninja.

Não vejo como isso muda alguma coisa?

Isso novamente nos leva à noção de um caminho seguro; sistemas como scripts sudo e build / CI definirão PATH como um bom padrão conhecido para evitar qualquer poluição potencial da construção, geralmente também sustentada por um chroot limpo.

Nesse caso, você pode evitar a modificação de PATH renomeando o binário ninja e colocando o script em seu lugar.

E aí vamos nós

Nesse caso, você pode evitar a modificação de PATH renomeando o binário ninja e colocando o script em seu lugar.

Isso é muito inapropriado de se sugerir.

Os usuários nunca devem se preocupar com binários de nível de sistema.

Não é apropriado para um sistema multiusuário para o binário de nível de sistema ser renomeado e substituído por um script.

Vou dizer novamente para registro: eu mantenho um sistema de construção sob medida para uma equipe de desenvolvimento C ++, ele compila alguns milhões de linhas de código C ++. Costumava fazer muitas coisas diretamente, mas agora gera arquivos ninja e as coisas estão felizes. Portanto, tenho algumas pistas para esfregar quando falo sobre isso.

O que eu quero: que o binário ninja reconheça uma única variável de ambiente que defina vários padrões, incluindo verbosidade e tal.

O que posso aceitar: Ninja responde a várias variáveis ​​de ambiente.

O que não é aceitável: necessidade de escrever um script de wrapper.

Por que isso não é aceitável: ao implantar no Windows, isso funcionaria bem, suponho. Mas não é aceitável no Linux, porque contamos com o pacote ninja do sistema para fornecer funcionalidade. Portanto, ao implantar em sistemas Linux, sua sugestão aqui é "Oh, apenas renomeie o pacote ninja de nível de sistema e substitua-o por um script" indica problemas de segurança e problemas de manutenção. Entre outras coisas, agora tenho que cuidar do sistema sempre que o pacote ninja for atualizado pelo gerenciador de pacotes do sistema.

Este não é um recurso arriscado para adicionar ao programa. O trabalho do Ninja não é proteger os usuários de si mesmos. Se um usuário de alguma forma conseguir estragar tudo, é culpa dele.

A probabilidade de adicionar um recurso como esse ao Ninja, reduzindo a velocidade do Ninja em mais do que alguns microssegundos, é tão baixa que chega a ser inexistente, mas sua proposta é usar um script de wrapper, que envolve a execução de um interpretador de script sempre que o ninja é lançado, o que é de longe mais sobrecarga do que algumas comparações de string em um binário já em execução.

Portanto, ao implantar em sistemas Linux, sua sugestão aqui é "Oh, apenas renomeie o pacote ninja de nível de sistema e substitua-o por um script" indica problemas de segurança e problemas de manutenção.

Não, ao implantar no Linux, minha sugestão seria colocar o script em /usr/local/bin .

Não tenho esse diretório na minha máquina Linux, aparentemente.

Não consigo encontrar referências a ele no padrão de hierarquia do sistema de arquivos http://www.pathname.com/fhs/pub/fhs-2.3.pdf

Eu encontrei uma referência a / usr / local / sbin no FHS, talvez seja isso o que você quis dizer? Parece estranho usar uma pasta "sbin" para isso.

Presumivelmente, / usr / local / bin deve estar no PATH antes de / usr / bin e outros.

No entanto, não foi isso que você disse. Você disse isso:

Nesse caso, você pode evitar a modificação de PATH renomeando o binário ninja e colocando o script em seu lugar.

E essa é uma sugestão ruim, repleta de problemas de segurança e manutenção contínua.

Colocar um script em um diretório de todo o sistema que está sempre incluído antes de todo o resto é uma maneira melhor de fazer isso do que renomear o binário e colocar um script em seu lugar.

No entanto, eu ainda estou para ver uma explicação de por que não estamos apenas incluindo isso no próprio ninja, que era autoconsistente, não adicionava um monte de sobrecarga ao chamar um script e / ou "todos precisam escrever seus script próprio agora ", e apontou para as diretrizes para o projeto ninja, conforme documentado aqui no github.

A reimplementação da linguagem de compilação Ninja independente https://github.com/michaelforney/samurai suporta isso por meio da variável de ambiente SAMUFLAGS. Simplesmente use o samu em qualquer lugar em que você usaria o ninja ou instale o samu como seu sistema / usr / bin / ninja (algumas distros Linux têm opções para instalar esta implementação concorrente como o padrão, ou apenas ninja).