Godot: Considere mover o sistema de construção para Meson ou outro sistema de construção

Pelo que entendi, o conjunto de ferramentas do sistema deve fornecer:

• Compilação cruzada (compilar para todas as plataformas de destino possíveis a partir da mesma plataforma host).
  
  
  
  • Por "possível", quero dizer que o host permite (então o macOS e o iOS só são possíveis em uma máquina Mac e a partir do Linux com OSXCross).
  
  
• Uma forma de gerar arquivos (tradução de PO, classes de shader de GLSL, dados de documentação de XML).
  
  
  
  • O SCons sabe que os arquivos gerados são dependências, portanto, alterá-los aciona uma reconstrução dos arquivos relevantes. Isso também deve ser considerado.
  
  
• Múltiplos destinos e opções dentro dos destinos (target = debug / release_debug / release, arquitetura como x86 ou ARM, 32 ou 64 bits).
• Opções para personalizar os alvos extras de construção / habilitação (gdnative wrapper, sem cola mono, habilitar / desabilitar: módulos, drivers, recursos obsoletos, etc., definir libs para compilar estaticamente usando o código embutido ou usar as libs do sistema, para cada um individualmente).

Não sei Meson, mas se fornece tudo acima deve estar bem (se eu não esqueci de algo). Claro, alguém tem que passar pela dor insuportável de reescrever o sistema de construção no Meson e então mostrar que as ferramentas e os tempos de construção são efetivamente melhores para Godot do que para SCons.

Observe que algumas dependências de terceiros requerem que um patch seja compilado com Godot. Percebi que o Wrap tem suporte para patch, mas parece que o patch deve estar disponível em algum lugar para download, embora eu ache que é mais fácil de gerenciar se eles ainda fizerem parte do repositório. Além disso, alguns deles requerem sinalizadores de compilação especiais que não devem ser aplicados a toda a construção.

Acho que essa prova de conceito seria muito valiosa porque

• dá-nos uma ideia melhor se o novo sistema de compilação lida com tudo o que precisamos e quão bem o faz
• nos dá dados concretos em vez de abstratos para discutir

Para o segundo ponto, isso significa que podemos ver a diferença na velocidade de construção para Godot , podemos ver o quão mais fácil (ou mais complexo) nossos scripts de construção se tornam e podemos comparar as diferenças mais facilmente para fazer uma escolha em vez de torná-los educados suposições baseadas no que achamos que ela poderia oferecer.

-

Agora, pessoalmente, tenho que dizer que não sou nem a favor nem contra isso, mas acho que há mais frutas ao alcance da mão para perseguir em vez de (ou antes?) Mudar todo o sistema de compilação. Especialmente neste momento crítico, onde tantas mãos quanto possível são necessárias para garantir que o 3.0 e os primeiros patches estejam na melhor forma possível. Mas se quisermos melhorar o sistema de compilação, eu examinaria os tempos de compilação do CI e o incômodo da situação de compilação Mono. (Penso que estes estão em Akien 's TODO / lista de aggrievances?)

Além disso, as compilações paralelas com bugs no Windows são péssimas, mas isso é mais em uma base pessoal "seria bom se fosse corrigido".

TL; DR:

• Eu concordo que a documentação / recursos do SCons estão faltando, os scripts de construção sendo fáceis Python de alguma forma neutraliza isso, IMO
• Como um novo contribuidor, o sistema de compilação Godot foi um dos menos irritantes de configurar, muito pouco tempo para a primeira compilação bem-sucedida
• Prefiro ver o esforço despendido na melhoria do 3.0 / 3.1 o máximo possível e talvez pensar sobre isso, uma vez que eles estejam estáveis
• Melhores tempos de compilação de CI e compilações Mono mais fáceis podem ser mais importantes

Minhas opiniões. :)

Eu realmente acredito que lançar o 3.0 e focar nas versões seguintes (3.0.1, 3.1) deve ter prioridade sobre isso, para registro.
Eu sei por que as pessoas não gostam de trabalhar em buildsystems (uma vez que é realmente apenas para o benefício de outros desenvolvedores / particularmente os usuários finais tech-savvy - que não é un importante, que vale a pena tornar a vida os devs' e colaboradores mais fácil , mas, em última análise, a felicidade dos usuários finais é o objetivo) e há toda essa coisa de "custo de oportunidade", ou seja, quando o tempo gasto (ou perdido / desperdiçado, dependendo de quem você perguntar) na melhoria do sistema de compilação pode ser gasto na melhoria do próprio projeto. (A menos que você seja como eu e não possa realmente trabalhar no lado C ++ das coisas de qualquer maneira.)

E, no final das contas, o SCons realmente "simplesmente funciona", o que para a maioria dos desenvolvedores provavelmente será bom o suficiente, então, embora isso seja algo que espero que aconteça, não estou prendendo a respiração para 3.1 ou mesmo 3.2, se ele ainda angariar apoio suficiente para realmente acabar sendo trabalhado para começar.

Dito isso, posso dar o pontapé inicial no POC no final desta semana em meu fork, para aqueles que estão dispostos a acompanhar o progresso nisso (e provavelmente me ajudar, já que não tenho muita experiência em escrever sistemas de construção), mas provavelmente não estarei abrindo uma solicitação de pull para isso por um tempo.

Eu realmente não acho que o SCons é lento, e sua flexibilidade (da qual tiramos muita vantagem) é provavelmente incomparável por qualquer outra coisa. SCons também é extremamente comprovado, eu acho que nunca estraga uma compilação.

Honestamente, a menos que alguém se voluntarie para reescrever todo o sistema de compilação (não apenas uma prova de conceito) e mostre que é mais simples (muito menos código) ou muito mais rápido , eu não consideraria nada mais, nem mesmo um pouco.

Agora, pessoalmente, tenho que dizer que não sou nem a favor nem contra isso, mas acho que há mais frutas ao alcance da mão para perseguir em vez de (ou antes?) Mudar todo o sistema de compilação.

Isso não é realmente prejudicial para essa mudança. Quer dizer, a maioria dos colaboradores do Godot trabalha no tempo livre e no que quer. Para o caso de @NullConstant , parece ser "faça isso ou não faça nada" (sem dizer que você não quer consertar as coisas, apenas que é mais difícil trabalhar com o código C ++ real e procurar bugs em algo desconhecido), então fazer isso é uma coisa boa em geral.

Além disso, o argumento "há coisas melhores para fazer" é a maneira de não ter nada feito IMO. É claro que nada será mesclado até que estejamos confiantes de que não quebrará coisas e não será feito perto de um lançamento. Concordo que há coisas mais importantes, mas isso não significa que não possa ser iniciado.

O fato é que alguém que está trabalhando nisso provavelmente terá que fazer isso sozinho. É claro que perguntas específicas podem ser respondidas pelos desenvolvedores principais, mas mais do que isso não acontecerá. É por isso que o SCons nunca foi considerado para ser substituído: ninguém até agora queria sujar as mãos. Como eu disse sobre o Bullet antes: alguém tem que fazer funcionar e provar que é possível e melhor, senão ficaremos com o status quo.

Mas acho que o SCons é lento. Não é muito lento, mas coisas como o status de progresso e o cache tornam as reconstruções mais lentas (usar E / S de disco para ler do cache torna-as lentas), então eu as desabilito durante a reconstrução. Demora um pouco para começar a fazer as coisas, depois disso é bem rápido.

Não sei se Meson será significativamente mais rápido, mas se alguém estiver disposto a tentar, não sou contra.

Claro, se alguém dedicar um tempo para fazer isso e mostrar que é uma melhoria grande o suficiente para justificar a troca, eu sou totalmente a favor :)

Como eu disse, não estou realmente equipado para lidar com a caça de bugs C ++ ou adicionar novos recursos nessa frente, então estou bem em fazer isso em vez disso.

Suponho que isso me dê (e / ou qualquer outra pessoa trabalhando nisso no futuro) uma meta bem clara e dupla para alcançar:

• faça Godot compilar com Meson em qualquer forma para começar
• torná-lo tão fácil quanto o SCons é no momento, possivelmente ainda mais (melhorando as velocidades)

E eu suponho que a velocidade do SCons não é terrível - terrível (a maior parte do tempo do processo de compilação vem da vinculação e compilação reais de qualquer maneira, então a lentidão da sobrecarga do sistema de compilação é provavelmente um tanto insignificante), mas certamente poderia ser melhorado, e oferecer o Meson como uma alternativa pode ser apenas essa melhoria. Veremos.

O maior problema é provavelmente substituir os scripts de compilação do Python por código de geração automática como os sombreadores, não parece que o meson tenha um recurso como esse.

e oferecer o Meson como uma alternativa pode ser apenas essa melhoria. Veremos.

Não deve ser uma alternativa, ou nós o adotamos se for claramente melhor, ou nem mesmo o oferecemos. Ter que oferecer suporte a dois sistemas de construção é uma loucura.

Certo, isso é justo.

Vou começar a hackear nos próximos dias / semanas, ver se isso vai a algum lugar e se é um esforço realmente válido (mesmo que eu acabe sendo a única pessoa trabalhando nisso o tempo todo).

Vou relatar se obtiver algo apresentável (como um benchmark).

Embora, não o meson, farei um teste nas próximas semanas para ver o que é necessário para construir godot no bazel para windows 64 bits no msvc.

O Bazel é outro sistema cuja vantagem é uma descrição de compilação mais curta e compilações mais rápidas. Também é mantido pelo Google, então não vai a lugar nenhum.

De qualquer forma, não posso verificar isso, mas é muito provável que 99% do tempo computacional gasto para construir Godot seja gasto no compilador. Portanto, mesmo que a sobrecarga do software de construção fosse nenhuma, isso levaria a uma redução de 1% do tempo de construção. Mesmo uma redução de 5% não valeria a pena, a menos que permita menos código e mais confiabilidade (ou se for provado que estou errado :)).

Para a velocidade de construção bruta de um clone limpo, duvido que haja alguma diferença significativa. Mas pode ser significativo se você considerar as velocidades de reconstrução. O SCons sempre reconstrói muitas coisas que não foram alteradas quando eu puxo um novo commit (especialmente OpenSSL e Bullet, que são grandes bibliotecas e demoram um pouco para construir).

Como eu disse antes, o SCons é lento para iniciar (leva alguns segundos antes de realmente começar a compilar). Se você está construindo o código-fonte inteiro que é insignificante, mas se você mudou apenas uma linha e está compilando para testar, isso pode melhorar significativamente o fluxo de trabalho (que IMO é o que mais importa no sistema de construção: ajudar as pessoas que trabalham com o código) . Portanto, 5s diminuídos em uma reconstrução de 10 minutos é irrelevante, mas 5s diminuídos em uma reconstrução de 10s é uma grande melhoria.

Mas concordo que qualquer mudança nesse sentido deve ser muito testada para provar que funciona. Como @reduz afirmou, o SCons nunca bagunçou uma compilação, e isso é algo a se considerar.

O Bazel é outro sistema cuja vantagem é uma descrição de compilação mais curta e compilações mais rápidas. Também é mantido pelo Google, então não vai a lugar nenhum.

Existe até uma categoria crescente na Wikipedia de "coisas que o Google descontinuou". :)

@mhilbrunner Não, ainda é mantido https://github.com/bazelbuild/bazel

O que eles queriam dizer era que só porque o Google o criou, não significa que vai durar muito tempo.

Já que adotamos o C # para o desenvolvimento de jogos, podemos também tentar algo como o Cake . Eu mesmo não tentei, então estou interessado em saber o que você acha disso. Por um lado, pelo menos, os scripts seriam executados mais rápido do que com Python.

Já que adotamos o C # para o desenvolvimento de jogos, podemos também tentar algo como o Cake .

Não tenho certeza se exigir uma instalação Mono para compilar Godot é uma boa ideia, considerando que Godot é principalmente um projeto C ++ e pode ser compilado sem suporte a C #.

O nível de desempenho oferecido pelo Meson ou CMake (com o gerador Ninja) deve ser mais do que suficiente para os propósitos de Godot.

@Calinou você provavelmente está certo, embora pareça que todos aderiram ao movimento C #, pessoalmente estou usando-o para scripts de jogos com Godot e aplicativos de produtividade com Xamarin.Forms, também se eu realmente quiser aumentar o desempenho, posso tentar algo como um conversor IL2cpp ou vá direto para C ++. Também estou pensando em usar o REPL mono / csharp e ASP.net para coisas que normalmente usaria JavaScript, Python ou PHP, como por exemplo coisas relacionadas a desenvolvimento web ou script de shell. Acontece que eu também não me importaria de ter um sistema de compilação baseado em C #, já que já o estaria usando para praticamente tudo. Pelo menos para mim seria o fim de "caramba ... outra linguagem que eu preciso aprender ... por que eles não ficam com C ++ e -inserir linguagem dinâmica / gerenciada decente aqui-"

Editar:

Para esclarecer, exigir que o Mono Framework seja instalado para construir Godot não parece tão ruim para mim, já que os chamados motores de jogo AAA exigem muito mais espaço em disco:

• Godot <50 MB
• Godot com suporte Mono (<50 MB) + Estrutura Mono (~ 350 MB ) = ~ 400 MB
• Unreal ~ 20 GB
• Unity ~ 10 GB
• CryEngine ~ 8GB

Além disso, poderíamos codificar o suporte Mono no editor por padrão e ter alguma lógica para detectar se devemos suportar scripts C # ou não em tempo de execução, e solicitar a estrutura Mono ou os modelos de exportação apropriados.

Eu amo o CMake, e meson parece legal, mas tendo a concordar com este artigo: http://www.rojtberg.net/1481/do-not-use-meson.

Estou muito interessado em fazer o footwork para mover Godot para Meson. A única coisa que atualmente me impede de contribuir com Godot (e de usá-lo) é o Scons. Tive de usá-lo anos atrás e nunca tive uma experiência de desenvolvimento incremental mais dolorosa em toda a minha vida.

O artigo linkado acima tem muitos argumentos de espantalho, argumentando que o CMake já existe e devemos apenas usar isso. Os arquivos de construção do Meson são extremamente fáceis de ler e usam uma sintaxe próxima à do Python. A conversão pode ser rápida. O que estou postando neste tópico é, se o footwork foi feito, uma solicitação de pull seria considerada para mesclagem?

O que estou postando neste tópico é, se o footwork foi feito, uma solicitação de pull seria considerada para mesclagem?

Será considerado, mas deve ser comprovado como vantajoso em relação ao SCons.

Depois de considerar o CMake apenas mais um sistema de construção e não o padrão de fato, você acaba com muitas opções. Por que meson em vez de SCons? Ou bazel / buck são ferramentas decentes também? Mas o maior argumento que tenho a favor do CMake são as ferramentas criadas para apoiar esse ecossistema. Bancos de dados de compilação do Clang, suporte para empacotamento para vários sistemas operacionais, etc. As únicas desvantagens válidas que ouvi são sintaxe e documentos ruins, mas isso não é realmente forte o suficiente para eu mudar minha posição sobre isso.

Por que meson em vez de SCons?

O Meson gera arquivos ninja, que são muito mais rápidos para o desenvolvimento incremental. Além disso, no Windows, você não precisa fazer nenhum tipo de manipulação de caminho de estúdio visual. Meson funciona fora da caixa. Usar meson sobre scons reduziria muito a sobrecarga das janelas de direcionamento, especialmente para aqueles que desejam usar o Visual Studio (do qual, devo observar, o meson pode gerar projetos assim como o CMake)

Ou bazel / buck são ferramentas decentes também?

Dado que bazel e buck são ambos escritos em Java (uma dependência que godot tem apenas se você for direcionar o Android, e mesmo assim, tecnicamente, pudesse usar apenas o NDK), eu diria que eles são uma dependência primária para todos Comercial. Python já está na lista de dependências, e você pode instalar facilmente meson (e ninja) por meio de um rápido pip install meson

Bancos de dados de compilação do Clang

Meson suporta isso por padrão, pois este é um recurso padrão integrado ao ninja

suporte para empacotamento para vários sistemas operacionais

Meson também tem suporte para isso, e depende muito do pkg-config quando apropriado

As únicas desvantagens válidas que ouvi são sintaxe e documentos incorretos

Meson tem uma sintaxe muito parecida com a do python, baseando-se em variáveis, objetos e funções embutidas. Na minha opinião escrever

my_meson_list = ['x', 'y', 'z']
message(my_meson_list)

vs

set(MY_CMAKE_LIST "x;y;z")
message(STATUS ${MY_CMAKE_LIST})

é muito mais fácil, especialmente considerando como o cmake às vezes diferencia maiúsculas de minúsculas e outras não. Quando você começa a entrar em expressões geradoras, pode ficar extremamente complicado.

# In one file
set(USE_STD_CXX11 "-std=c++11")
set(USE_STDLIB_LIBCXX "-stdlib=libc++")

# Possibly elsewhere
set(LIBCXX $<BOOL:${CAN_USE_STDLIB_LIBCXX}>,$<BOOL:${BUILD_WITH_LIBCXX}>)
set(NO_RTTI $<BOOL:${CAN_USE_NO_RTTI}>,$<BOOL:${DISABLE_RTTI}>)

# Later on...
target_compile_options(my-exe
  PUBLIC
  $<$<BOOL:${CAN_USE_STD_CXX11}>:${USE_STD_CXX11}>
  $<$<AND:${LIBCXX}>:${USE_STDLIB_LIBCXX}>
  $<$<AND:${NO_RTTI}>:${USE_NO_RTTI}>
  # Oh yeah, you're gonna want more of these, because you can't trust compiler interfaces
)

# Generator expressions mean you can't follow the flow of the build to see what is called and defined where. This is a completely valid use of CMake.
check_cxx_compiler_flag(${USE_STDLIB_LIBCXX} CAN_USE_STDLIB_LIBCXX)
check_cxx_compiler_flag(${USE_NO_RTTI} CAN_USE_NO_RTTI)

O méson equivalente se parece com:

cxx = meson.get_compiler('cpp')
# This is an extremely simplified approach. One can do a different option when dealing with MSVC and gcc support.
args = compiler.get_supported_arguments('-std=c++11', '-stdlib=libc++')
add_project_arguments(args)

Acho que devo observar, a propósito, que de todos os sistemas de construção C ++ que existem, Meson é o menos terrível . Os argumentos contra o seu uso tendem a ser a imagem de uma história em quadrinhos da web, alguns acenando sobre como CMake é o mais usado, então você deve apenas lidar com isso, e "ei, pelo menos CMake não é autotools".

Mas acima de tudo (e eu acho que isso é uma coisa realmente importante, especialmente para aqueles que usam godot como gdnative), Meson suporta cabeçalhos pré-compilados nativamente. O CMake não (e usar cotire para hackear a construção pode causar mais problemas do que vale a pena).

Não posso dizer o quanto isso pode acelerar a construção para usuários gdnative, mas será um aumento significativo no gcc e msvc (no mínimo, um aumento de desempenho no msvc é inevitável). Adicione o uso de extern template para as pequenas quantidades de código modelo encontrado em godot, e você poderá ver melhorias decentes no tempo de construção, que são importantes para compilações iterativas e incrementais.

O Meson gera arquivos ninja, que são muito mais rápidos para o desenvolvimento incremental.

Observe que o CMake também pode gerar arquivos de construção Ninja em vez de Makefiles tradicionais; isso é feito passando -G Ninja para sua linha de comando. Funciona muito bem na maioria dos projetos que experimentei e é um pouco mais rápido no geral (além disso, ele usará todos os threads da CPU por padrão).

O Meson ainda vence nas comparações de desempenho bruto que vi, mas isso definitivamente ajuda a fechar a lacuna entre o desempenho do Meson e do CMake.

Sim, no entanto, o CMake não instala automaticamente o ninja para você e não é o gerador padrão. A maior parte do tempo do CMake é gasto configurando o projeto, em minha experiência, e embora as versões recentes do CMake tenham melhorado muito o desempenho, nem todos terão o CMake mais recente.

OK, isso é bastante completo! Fico feliz que você tenha uma boa ideia dos recursos que valoriza em um sistema de compilação. Ainda acho que deve haver um sistema de construção padrão no mundo C ++ em que os projetos possam confiar. Eu só queria que o meson fosse um transpiler CMake ao invés de seu próprio.

Ainda acho que deve haver um sistema de construção padrão no mundo C ++ em que os projetos possam confiar.

Acredite em mim, ninguém quer isso mais do que eu. Eu me tornei uma espécie de goblin do lixo do sistema de construção e até dei uma palestra sobre eles na CppCon. Infelizmente (ou felizmente?) Me importo muito com sistemas de construção, quase ao ponto da obsessão. :)

Só quero dizer isso, mas sempre que fiz uma longa compilação do Godot no Windows, observei que o Python ocupou consistentemente> 15% da minha CPU. Duvido que só comece devagar.

Quem vai fazer um pequeno protótipo de motor godot construído com meson? Nunca cheguei ao ponto de criar um pequeno teste para bazel.

Uma compilação 2d apenas de godot deve ser suficiente para testar com todas as opções desabilitadas.

O primeiro obstáculo que enfrentei foi core / make_binders.py. Este é o código gerado automaticamente que Godot usa.

Fiz um protótipo inicial no sistema de compilação Bazel, mas discutirei a configuração em outro problema. https://github.com/godotengine/godot/issues/18518

Não tem tempo durante a semana, mas outros podem expandir no Bazel BUILD.

Lol como o Bazel se envolveu?

Visto que pode haver uma oportunidade única de mudar para um sistema de compilação diferente, não deveríamos procurar as melhores opções possíveis? Eu, pelo menos, estaria interessado em ver um gráfico de comparação Cake vs Bazel vs Scons, embora deva admitir que não tenho nenhuma experiência com o Cake para fazer o footwork para esses testes.

@rraallvv você quer dizer Bolo ou CMake?

@isaachier Que pena, estava falando sobre www.cakebuild.net , deveria ter sido mais específico, desculpe por isso.

Isso não é apenas para C #?

@isaachier Eu realmente não sei, todo esse tempo eu estava assumindo que o Cake era capaz disso, assim como o SCons sendo escrito em Python e tendo suporte para C ++. Mesmo assim, eu acabei de perguntar no gitter chat , vou postar aqui a resposta novamente.

@rraallvv para registro Eu acho que a ideia de uma comparação lado a lado dos principais sistemas de construção é uma ótima ideia. Aqui está o que eu encontrei online que considero bastante imparcial (não escrito pelos desenvolvedores do sistema de compilação): https://carlosvin.github.io/posts/choosing-modern-cpp-stack , https: //www.reddit. com / r / cpp / comments / 6euc7b / build_systems_bazel_buck / die6g1y / , https://stackoverflow.com/a/12022652/1930331.

Minha opinião pessoal:

• CMake : Linguagem bastante feia, mas onipresente e praticamente o padrão da indústria.
• SCons : status lento, antigo e IDK. Usa Python.
• mesão : Novo sistema de compilação baseado em Python que não é incrivelmente lento. A principal desvantagem é a trajetória. Não está claro se este será apenas mais um sabor do sistema de compilação da semana.
• Autotools: Ancient, nenhum suporte de ferramentas (ou seja, bancos de dados de compilação de apoio autocomplete Clang ou análise estática). Sem suporte para Windows. Evite a todo custo.
• bazel : Um gerenciador de pacotes / sistema de compilação do Google em um só. Não adiciona muito mais do CMake com um plugin como o Hunter . Além disso, o software do Google tende a se concentrar nas necessidades do Google, não no público em geral. Muito novo para avaliar a trajetória de longo prazo.

Eu tento empurrar o CMake sempre que posso, porque quero um padrão de fato para C ++ e o CMake tem a maior "participação de mercado" no momento.

@isaachier Obrigado por compartilhar essas informações, estou empurrando C # já que não há um sistema de compilação que suporte scripts em C ++, pode parecer bobo, mas não sei por que alguém não fez isso ainda, por exemplo, este C ++ REPL pode ser usado para um sistema de construção se alguém quiser ir para o próximo nível e encerrar o debate sobre qual é o melhor, mais rápido, etc.

Não entendo. C ++ provavelmente seria uma linguagem de construção horrível. A lentidão tem mais a ver com o núcleo do sistema de construção interno AFAIK, não com os detalhes da linguagem de script usada.

@isaachier Meu palpite é que SCons é tão lento porque foi escrito em Python, mas se alguém pegasse a tarefa de portar todo o sistema de compilação para C ++ e também torná-lo JIT, compilar scripts C ++ para executar essas compilações, seria muito mais rápido. Talvez o mesmo possa ser verdade para todos os sistemas de compilação existentes.

É uma boa ideia, mas o méson não é considerado lento pela maioria das contas, embora seja escrito em Python.

Duvido que o méson seja um sabor da semana, já que o projeto GNOME está atualmente abandonando as ferramentas automáticas em favor do méson.

Além disso, o Scons é lento não porque foi escrito em python, mas porque também executa a compilação. É um sistema de construção direta, como make ou ninja, mas também usa grandes quantidades de XML para definições e uma grande parte de seu código é, na verdade, apenas conversões de XSLT.

O Meson, por outro lado, executa seus scripts de construção para gerar uma árvore de dependência e, em seguida, despeja isso em um arquivo ninja. Meson é rápido, porque o ninja é rápido. Além disso, nem tudo é uma string em Meson, como em CMake.

Por último, devo observar que existem vários sistemas de compilação de desenvolvimento onde você será capaz de fazer scripts em C ++ (na verdade, estou escrevendo um deles). No entanto, pedir a Godot para mudar para um sistema de compilação que ainda não existe ( e pior, que eu mesmo estou escrevendo) é um pouco arrogante, na minha opinião não tão humilde;)

Também quero reiterar que, no atual fluxo de trabalho de desenvolvimento, o python é uma necessidade. O mesão também. E isso torna a mudança para o méson tão simples quanto chamar a ferramenta pip do python.

Concordo totalmente @reduz que também não acho que o SCons seja lento.

Como @ slurps-mad-rips disse:

Scons é lento não porque é escrito em python, mas porque também executa a compilação

homem scons:

scons suporta a construção de vários alvos em paralelo por meio de uma opção -j que leva, como argumento, o número de tarefas simultâneas que podem ser geradas:
scons -j 4

Eu tenho uma CPU com 8c16t, então use "scons p = x11 -j 18" é muito rápido para mim.
É 10x mais rápido do que usar "scons p = x11" como configuração padrão "-j 1".
Alguém tem uma CPU de núcleo único no ano 2018?
Deixe sua CPU funcionar totalmente.
Por favor, tente.

Nem todo mundo tem essas CPUs grandes, mas o mais importante, o meson (bem, ninja) é muito mais rápido em recompilações incrementais. O Scons, por padrão, executa uma soma hash MD5 para ver se um arquivo foi alterado. Godot usa a configuração de carimbo de data / hora MD5, o que significa que só fará o hash de um arquivo se o carimbo de data / hora tiver sido alterado. Ainda é ridículo.

Acho que a melhor maneira de provar o que é melhor é escrever um novo e ver :)

O Scons não é rápido para muitas pessoas, especialmente para usuários do Windows que enfrentam problemas com qualquer coisa acima de -j 1.

@ slurps-mad-rips depende do projeto. ninja parece exagerar um pouco demais em sua velocidade. Consulte este artigo: http://david.rothlis.net/ninja-benchmark/. Parece que contar arquivos de origem é sua melhor aposta aqui. Se <20K não fará muita diferença.

@isaachier esse benchmark é entre make e ninja, não ninja e scons, então você vai ter que me perdoar se eu não quiser prestar atenção nisso. ;)

Acho que a melhor maneira de provar o que é melhor é escrever um novo e ver :)

Eu concordo, não há sentido em trocar de bicicleta. Se você tem uma opinião sobre um sistema de construção melhor, implemente-o e prove que é melhor. Caso contrário, esta é uma discussão de opinião e não levará a lugar nenhum. @fire já fez um teste parcial com o bazel: https://github.com/godotengine/godot/issues/18518.

@ slurps-mad-rips ya tópico totalmente diferente, não SCons. Só quis dizer que fazer contra ninja não é uma diferença louca.

Pequena atualização: estou desistindo de tentar passar para o méson. Tem sido fragmentado e enquanto os arquivos de construção são ligeiramente mais fáceis de ler, ficar atualizado com o sistema atual é onde a maior parte do meu (agora raro e escasso) tempo livre é gasto, em vez de mover scons para meson.

No momento, muitos códigos e operações são colocados diretamente nos scripts scons e isso torna a mudança para outro sistema de compilação mais difícil. Se qualquer coisa, eu diria que tempo deveria ser gasto desacoplando os scripts python existentes que geram código de scons, já que isso faria uma mudança para outro sistema de compilação como meson, cmake ou mesmo bazel muito mais fácil.

Ainda bem que um patch foi fundido para remover toda a geração de código. https://github.com/godotengine/godot/pull/17595 Não desista!

SCons Project Co-Manager aqui. Algumas notas:
1 - O SCons está em desenvolvimento ativo e, desde a nossa migração para o Github, estamos vendo um aumento na taxa de solicitações de pull.
2 - Identificamos algumas partes específicas do SCons que são responsáveis ​​por cerca de 50% do tempo de construção incremental nulo e estamos trabalhando ativamente para resolver isso. (A funcionalidade Subst)
3 - Começamos a oferecer suporte a Python 3.5+ (bem como 2.7.x) com SCons 3.0
4 - Deixe-me sugerir que, em vez de tentar portar para N sistemas de construção diferentes, contribuir com algum tempo para ajudar a melhorar SCons pode ser um uso mais eficaz do tempo do desenvolvedor
5 - Identificamos e abordamos por meio de perfis alguns dos pontos mais fáceis de melhorar o desempenho que foram lançados em 3.0.0 e 3.0.1. Se você estiver usando uma versão anterior, a compilação incremental nula pode ser de 5 a 15% mais lenta. (assumindo Python 2.7.x)

Como sempre, o projeto SCons está pronto e disposto a ajudar os projetos que usam o SCons nos problemas que encontram.

Algumas "estatísticas" para SCons e godot.

Eu usei (e ainda uso) um Q6600 que é uma CPU de 4 núcleos de 2008 ou mais com 2.4GHZ (e uma contagem de instruções mais baixa por ciclo) do que os processadores que "todos" estamos usando hoje (i7s).

No Q6600, uma construção demorava entre 3 a 5 minutos (ou mais, mas o número exato não é tão importante), dos quais cerca de 35-40 segundos foram gastos pelo SCons analisando a árvore de dependências e outras coisas (o trabalho de preparação) ... então, 80% do tempo gasto executando o processo cl.exe (compilador MSVC) repetidamente.

Portanto, em termos de desempenho e otimização, a menos que SCons (python realmente, não SCons) tenha um sistema de chamada de processo terrível que está levando mais tempo do que deveria ou alguma outra ferramenta não esteja compilando um arquivo por processo (como SCons atualmente está) e o 1 A sobrecarga do processo por um arquivo é significativa (não sou um especialista em processos internos de compliação e sobrecarga de inicialização de cl.exe), a única otimização de desempenho que um sistema de compilação mais rápido produziria é provavelmente na fase de construção da árvore de dependência e outra preparação para complicações .

Então, estamos otimizando aqueles 35-40 segundos de uma compilação de 5 minutos (no i7 agora estamos provavelmente otimizando uma etapa de configuração de núcleo único de 20 segundos de uma compilação de vários núcleos de 3 minutos).

Então, para recapitular, se bem me lembro, 3 a 5 min é na verdade uma compilação de vários núcleos de 4

Portanto, "otimizar" SCons significa mais ou menos otimizar os primeiros 35 segundos do início das compilações ...

Isso é no que diz respeito às "otimizações" quando se trata de SCons versus outro sistema de compilação mais rápido ... É possível que a compilação real possa ser otimizada um pouco evitando chamar um único cl.exe para cada arquivo obj, mas isso só se a sobrecarga do processo é significativa (temo que o HDD sempre será o verdadeiro gargalo de E / S (e não a CPU), o que não é evitável / mitigável sem um SSD)

Todos esses parágrafos acima consideram uma "construção completa". Dito isso, SCons "trapaceia" se tudo já está compilado e passa nas verificações de consistência pesadas, então se você alterar um único arquivo, ele irá compilar um "único arquivo" e, em seguida, vincular tudo de volta, fazendo uma "compilação completa" em algo de uma construção incremental). No entanto, isso requer aqueles 35-40 segundos de pré-computação total da árvore de dependência ...

Então, uma "compilação incremental" é de cerca de 45 segundos no meu computador antigo, e eu pensei quando eu era um novato, 2 anos atrás, que seria limitado pela CPU, mas na verdade, pode ser limitado pelo IO (verificando vários milhares de arquivos no disco rígido ) para uma varredura de dependência completa / reconstrução de árvore ... Então, se for ligado por E / S, nenhum "sistema mais rápido" vai resolver isso ...

Minha ideia hackeada de 2 anos atrás era tentar anexar um "observador" do sistema de arquivos ao SCons, fazer com que o SCons executasse e recompilar um único arquivo alterado (e suas dependências, isso é automático) e, em seguida, apenas vincular tudo de volta ... embora eu saiba hoje que a vinculação provavelmente ainda executaria uma varredura de dependência completa ... dito isso, a varredura / reconstrução da árvore de dependências pode ser eliminada com uma opção e o SCons usará sua árvore de depósito em cache ... o que economiza cerca de 15-20 segundos da etapa de pré-computação de 35 segundos (os primeiros 15 segundos parecem inevitáveis), embora isso possa não garantir uma compilação "perfeita" sempre como o SCons faz (embora isso possa não ser importante para compilações incrementais no desenvolvimento ... se você decidir que a velocidade é uma troca digna).

Agora tenho conhecimento suficiente para poder hackea-lo por meio do npm e do npm watch ... e ou outro sistema com o qual não estou familiarizado no momento ... Mas isso é para mais tarde, e quando eu tiver tempo (não atualmente).

Isso está ficando um pouco longo, então vou encerrá-lo aqui, mas o objetivo desses parágrafos era dar a você algumas informações "estatísticas" em vez de desencorajar alguém (vá em frente se você gosta de trabalhar em sistemas de construção), como eu mesmo gostei consertar algumas coisas nos SCons de Godot. Espero que algumas informações tenham sido úteis para vocês aqui.

Se você deseja replicar / refazer minhas estatísticas, basta navegar pelos documentos do SCons até ativar as informações estatísticas (coisas de temporizadores) e / ou encontrar uma maneira de desligar a redução de dependência (os primeiros 20 a 30-35 segundos de "pré-computação" ) ...

Ou para uma solução um pouco menos manual, as informações de depuração do cronômetro já devem estar presentes (editar: não é provável, alguém fez o que parece ser uma atualização interessante para a geração do projeto vs, este parágrafo pode ser uma informação desatualizada) no projeto VS automatizado gerado por SCons (no final do arquivo SConstruct) ... você pode encontrar informações sobre como gerar um projeto VS no "tutorial de compilação do Windows" no site da godot. Você pode então executar o SCons do VS, acredito que o projeto gerado provavelmente ainda deve funcionar, embora eu não tenha testado no Godot 3 ... É uma opção, mas seguir scons para a> log.txt também é outra opção (etc) ...

Espero que alguém tenha achado esta informação útil.

@Griefchief Só para esclarecer um pouco as coisas, acho que não estamos tentando otimizar os tempos de compilação completa, já que esses são dominados pelo tempo do compilador de qualquer maneira. Em vez disso, queremos otimizar compilações incrementais onde apenas um único arquivo de origem é alterado.

Na verdade, o "build incremental nulo" (nada realmente precisa ser reconstruído, mas o scons ainda precisará processar toda a árvore de dependência para garantir isso) é o caso em que estamos trabalhando.

Alguns perfis apontaram algumas ineficiências no processamento das linhas de comando (que devem ser feitas para cada destino para garantir que eles não tenham mudado) foram identificadas. A maior parte disso é a lógica Subst (). Este é um código complicado e até agora foi implementado de uma maneira mais simples e segura, mas não de forma tão eficiente.

Outro ponto quente é a leitura e gravação dos arquivos sconsign, atualmente implementados com cpickle e sempre lidos e gravados como um todo. Temos algumas idéias sobre como acelerar e / ou fazer mais incrementais. De qualquer forma, observe os próximos lançamentos para melhorias.

Em uma nota lateral, você pode tentar MSVC_BATCH para ver se isso acelera as compilações do seu Windows:

MSVC_BATCH
Quando definido com qualquer valor verdadeiro, especifica que o SCons deve compilar em lote os arquivos de objeto ao chamar o compilador Microsoft Visual C / C ++. Todas as compilações de arquivos de origem do mesmo diretório de origem que geram arquivos de destino em um mesmo diretório de saída e foram configuradas no SCons usando o mesmo ambiente de construção serão construídas em uma única chamada para o compilador. Apenas os arquivos de origem que foram alterados desde que seus arquivos-objeto foram construídos serão passados ​​para cada chamada do compilador (por meio da variável de construção $ CHANGED_SOURCES). Todas as compilações em que o nome da base do arquivo de objeto (destino) (menos o .obj) não corresponder ao nome da base do arquivo de origem serão compiladas separadamente.

@ bojidar-bg sim, sim, eu estava falando sobre compilações incrementais também, obrigado pela dica: D

@bdbaddog Oi baddog, apenas para sua informação, eu realmente escrevi este grande comentário meu antes de ver seu comentário, então, ele não se refere a nada em seu comentário especificamente ... mas você conseguiu mencionar alguns dos " preocupações "Eu tinha (informações para outras pessoas, na verdade) enquanto estávamos escrevendo nossos comentários ao mesmo tempo ...

E eu não queria te enviar porque não queria "desperdiçar" seu tempo: D, mas acho que vou passar mais tempo construindo / consoles de godot no futuro (eu pretendo, eu estou muito ocupado))

Obrigado por sua contribuição aqui!

@bdbaddog BD, já que você está fornecendo suporte, se posso perguntar aqui:

Se eu anexar o npm watch ao sistema de arquivos (fonte de godot) e souber qual arquivo exato foi alterado, isso me traria algum benefício com o SCons?

Agora posso executar scons por meio do npm watch e enviar o arquivo para ele ...

scons [opções de godot] o / arquivo / que / foi / alterado.

isso obviamente recompilará esse arquivo, provavelmente evitando toda a árvore dep de Godot. correto? Portanto, agora a travessia da árvore dep não levará 20 segundos, mas menos de 1 problema, mas recebo 1 arquivo .obj atualizado (ou mais, depende do que você alterar). Ele não vai realmente percorrer toda a árvore do godot dep para aquele arquivo? Eu tenho uma vantagem em menos travessia da árvore dep neste exemplo (e possivelmente outras vantagens na fase de pré-computação que não podem ser obtidas através da reutilização do cache da árvore dep, como menos arquivos gerais para passar?).

Agora, se eu tiver uma vantagem e se eu quiser apenas vincular tudo novamente, precisarei de uma travessia completa da árvore para uma fase de vinculação "simples"?

Eu entendo que este caso de uso pode não ser suportado atualmente pelo Scons (basta vincular tudo novamente), mas estou perguntando do ponto de vista prático e teórico. Sei que a árvore de depósito em cache poderia ser reutilizada com a opção "não fazer árvore de dep" (esqueci, já se passaram dois anos), e isso funcionaria para alguns casos de uso, e que o caso de uso não contém novos arquivos adicionados, correto ? (o npm watch poderia me alertar sobre a adição de um novo arquivo e eu poderia então fazer uma atualização completa da árvore dep se detectar isso ... em outras palavras, meio que enviar "garantir a consistência da árvore dep" de volta para um observador de arquivos como npm watch, automatizar digitando naquela opção "usar cache de dependência" feita manualmente pelo usuário para um programa como o npm watch ... deixe o programa se preocupar com a consistência, não o usuário, e faça isso em "tempo real", no momento em que o usuário salvou um arquivo, dando muito mais tempo para os scons fazerem sua coisa)

Existe algo na minha ideia que não funcionaria como uma otimização (prática e teoricamente), e você tem outras sugestões (que não precisam garantir uma construção perfeita se algo como o relógio npm pode cuidar das coisas, está bem também )? Você pode aconselhar por favor? Obrigado!

Para recapitular, o caso de uso é semelhante a este:

1) execute um filewatcher como o npm watch no diretório de origem de godot
2) o usuário salva / modifica um arquivo antigo
3) scons é executado imediatamente para esse arquivo pelo npm.
4) se a compilação for bem-sucedida, o npm instrui o scons a executar o vinculador e vincular o executável.

4.1) se a árvore dep for descontada (uma compilação completa já foi executada), o npm pode instruir o vinculador a apenas vincular neste ponto a uma versão em cache da árvore dep
4.1) se nenhuma árvore dep em cache for detectada, o npm watch executa uma compilação completa do godot
4.2) se a invalidação do cache for detectada, como adicionar um novo arquivo, execute uma travessia completa da árvore de depósito (o npm não usará a opção "usar árvore de depósito em cache" com scons).

Espero que isso torne minha ideia um pouco mais fácil de entender, por favor, deixe-me saber o que há de errado com ela neste momento; D

PS Eu acredito que este é o comando que tira 15 segundos do build incremental nulo de 35, com suas consequências "óbvias" ... Eu basicamente quero automatizar o que está descrito aqui (mais ou menos, + deixe os scons saberem qual arquivo exato foi modificado se isso ajudar de alguma forma (ou se pudesse ajudar)):

https://www.scons.org/doc/latest/HTML/scons-user/ch06s04.html

Algumas coisas aqui (sem uma ordem específica, mas estou usando números porque yolo

1) As compilações nulas incrementais não são basicamente nada em qualquer ferramenta que gere arquivos ninja. O Chrome tem, AFAIK, uma construção incremental nula de menos de 2 segundos. Isso é importante, pois uma queda de 35 segundos para 15 abaixo de npm watch ainda é muito grande em comparação com uma construção Ninja baseada em meson ou cmake. O Ninja também faz a mesma coisa que o Scons, ao realizar uma reconstrução caso a linha de comando mude (o make, é claro, não faz isso)

2) O CMake implementou recentemente a capacidade de usar CONFIGURE_DEPENDS como um argumento para o sistema glob. Isso sempre foi recomendado porque ferramentas como xcodebuild e msbuild historicamente (e atualmente) não suportam a detecção de mudança de diretório. Isso é, afaik, uma coisa que Scons poderia melhorar, mas não tenho tempo nem paciência para mergulhar fundo no projeto e implementar isso. Basicamente, todo sistema operacional atualiza um diretório quando seu conteúdo muda, seja um arquivo adicionado, modificado ou removido. Ao fazer alterações incrementais, pode-se simplesmente verificar quais diretórios foram alterados e glob apenas aqueles em uma verificação de reconfiguração. Isso pode reduzir o trabalho realizado, pois você não está globalizando a árvore inteira, mas partes menores. Para pequenos projetos, isso é bom. Se isso beneficiaria Godot ou não, exigiria alguns testes e é muito trabalhoso verificar se ajudaria.

3) Embora seja bom ver que os Scons estão recebendo mais atenção, eu pessoalmente acho que é melhor para a comunidade em geral que godot mude para um sistema de compilação mais usado. Não consigo pensar fora de godot em qualquer grande projeto que use Scons. GNOME / GTK recentemente mudou para meson (pulando o CMake), o KDE está no CMake há algum tempo. Embora seja uma evidência anedótica (e, portanto, um viés de confirmação básico), conheço vários desenvolvedores C ++ que gostariam de tentar o godot, mas preferem não ter que tocar nos scons nunca mais. Remover as experiências desagradáveis ​​e, portanto, o gosto azedo que ficou na boca dos desenvolvedores é difícil e, honestamente, desejo o melhor ao projeto Scons. Mas eu sei que a comunidade C ++ em geral já odeia muito tempo de compilação. Longas compilações incrementais nulas (ou mesmo longas compilações incrementais de 1 arquivo) são um pesadelo no mundo moderno.

Tenho a intenção de tentar novamente, mas posso direcionar o CMake para isso. Mover de CMake para méson é muito mais fácil graças ao méson ter um script de conversão que pode fazer muito trabalho. CMake pode tornar o tratamento de dependências um pouco mais fácil com o novo módulo FetchContent. Vamos ver como isso funciona. Devo dizer que estou feliz por esses scripts codegen terem sido movidos para arquivos separados. Usar o CMake será bom porque mudar para um padrão C ++ diferente é tão simples quanto target_compile_features(<target> (PUBLIC|PRIVATE|INTERFACE) cxx_std_<number>)

Obviamente, qualquer coisa relacionada ao sistema de construção vai ser contenciosa, mas tentar não pode machucar.

Para ser bem honesto, (e isso pode soar insensível), não tenho nenhum desejo de mergulhar fundo no projeto Scons para melhorá-lo. Talvez depois de 2020, quando o Python 2.7 estiver oficialmente finalmente morto e o projeto puder avançar para o Python 3.5+, valerá a pena investigar ou melhorar, possivelmente com operações assíncronas. Até então, porém, prefiro não ter que tocá-lo.

Talvez depois de 2020, quando o Python 2.7 estiver oficialmente finalmente morto e o projeto puder avançar para o Python 3.5+, só que valerá a pena investigar ou melhorar

Scons 3 oferece suporte a Python 3.5+: https://scons.org/tag/releases.html .

Eu realmente não entendo como alguém pode não gostar tanto de Scons e gostar da bagunça de configuração que é CMake, onde é ainda difícil definir suas próprias configurações de construção se você for um usuário, difícil de entender quais são as opções e seus tipos e quais são definições internas, só me trouxe dor, e fiquei realmente aliviado por Godot não ter usado.

Em qualquer caso, se você acha que vai ser uma solução melhor, vá em frente e tente, eu posso acabar mudando minha visão no CMake.

onde é ainda difícil definir suas próprias configurações de compilação se você for um usuário,

Se isso for solicitado, o CMake está sendo usado incorretamente. Todas as configurações do conjunto de ferramentas devem estar em um arquivo do conjunto de ferramentas e quaisquer configurações específicas do projeto são passadas por meio de sinalizadores (ou gui ou edite o arquivo de cache ou qualquer outra coisa). Tudo é documentado e digitado, até mesmo os autores do projeto podem documentar e digitar sua configuração exposta. Você deve ler CGold e os padrões modernos do CMake.

@Faless ninguém nega que a linguagem CMake é terrível. Mas a implementação é a melhor da classe. Estive considerando a possibilidade de escrever um transpiler de uma linguagem melhor para amenizar o problema.

@ OvermindDL1 adorou a sugestão de ler CGold.

Se isso for perguntado, o CMake está sendo usado incorretamente

Bem, eu acho que todos os programas que encontrei estavam fazendo isso errado.

Para ser honesto, eu odeio ter que mudar de sinalização via -DI_LOVE_CMAKE_AND_MAKE_DEFINES_LONG=on (realmente? on ?). Sem falar na ideia de editar o arquivo de cache O_o. Ou que, se eu quiser mudar um sinalizador, basicamente acabo tendo que excluir a pasta de compilação e começar do zero (porque, você sabe, o cache é diferente!) ... tanto para compilações incrementais ...

EDIT: Além disso, uma coisa que eu realmente gostei sobre Scons (em Godot, pelo menos, e isso pode ser possível com outro sistema de compilação, é claro), é que eu realmente não li nenhum padrão ou documento, apenas executei scons -h na pasta Godot

95% dos arquivos de compilação que vi no GitHub estão errados. As pessoas ficam preguiçosas ao criar sistemas e seguir as práticas do culto à carga para consertar algo.

@isaachier , apenas como uma métrica, você poderia fornecer 2 exemplos de um arquivo CMake ruim e bom? Como você consideraria isso: https://github.com/ARMmbed/mbedtls/blob/development/CMakeLists.txt ?

Melhor do que a maioria que já vi. Ainda assim, se você não estiver usando o CMake> = 3.0, então sua experiência com o CMake não é moderno.

Bem, eu acho que todos os programas que encontrei estavam fazendo isso errado.

Costumo ver isso bem feito hoje em dia.

Para ser honesto, odeio ter que mudar os sinalizadores via -DI_LOVE_CMAKE_AND_MAKE_DEFINES_LONG = on (realmente? On?). Sem falar na ideia de editar o arquivo de cache O_o. Ou que, se eu quiser mudar um sinalizador, basicamente acabo tendo que excluir a pasta de compilação e começar do zero (porque, você sabe, o cache é diferente!) ... tanto para compilações incrementais ...

Você não precisa usar on , você pode usar true , 1 e uma variedade de outras coisas. É para fazer com que você possa escolher um nome booleano apropriado que flua bem com o nome do sinalizador.

E você nunca deve precisar reconstruir a pasta de construção se alterar as opções, cmake é excepcionalmente bom em reconstruir quando necessário.

Ainda assim, todos que tocam em sistemas de construção C / C ++ devem ler CGold , bem como o manual oficial do CMake. É realmente fácil de usar CMake direito, muitas vezes é muito mais curto também. As antigas metodologias CMake2 não deveriam ser utilizadas. Na verdade, qualquer pessoa que dependa de uma versão do CMake 2.x está absolutamente fazendo coisas erradas (não usando alvos e conjuntos de ferramentas corretamente, não definindo opções corretamente, etc ... etc ...).

Obrigado pelas explicações, embora continue cético, estou ansioso para ver como funcionaria para Godot :).

@ slurps-mad-rips Sua postagem com o suposto código de exemplo CMake para habilitar o modo C ++ 11 é totalmente fora do padrão CMake por uma variedade de razões, incluindo, mas não se limitando a:

• Configurando variáveis ​​não expostas.
• Argumentos do conjunto de ferramentas definidos em um arquivo que não é do conjunto de ferramentas.
• Absolutamente não como você faz algo como habilitar o modo C ++ 11.
• Ineficiente.

Dado o código de meson auto-descrito como simplificado mostrado nessa postagem de:

cxx = meson.get_compiler('cpp')
# This is an extremely simplified approach. One can do a different option when dealing with MSVC and gcc support.
args = compiler.get_supported_arguments('-std=c++11', '-stdlib=libc++')
add_project_arguments(args)

O equivalente simplificado (em que você também pode adicionar mais propriedades) CMake seria:

set_target_properties(godot PROPERTIES CXX_STANDARD 11)

E isso garantirá que o conjunto de ferramentas usado saiba que precisa definir esse modo (e você pode especificar como lidar com as falhas se estiver usando um compilador que não o suporte também). Assumir sinalizadores de linha de comando específicos do compilador especial no arquivo de construção é uma forma extremamente pobre, visto que deveriam existir apenas em arquivos de conjunto de ferramentas e o fato de o exemplo de meson mostrado na postagem anterior realmente especificar argumentos específicos essencialmente significa que você está codificando os compiladores suportados.

Considerando que existe um arquivo CMake Toolchain pré-construído para praticamente qualquer conjunto de ferramentas que você possa imaginar (incluindo todos os padrões de MSVC de várias variedades, GCC / Clang, android, iOS, emscripten, etc ... etc ...), você não deveria reinventar a roda. Se o usuário que está compilando algo como godot deseja usar seu próprio compilador personalizado com argumentos de linha de comando exclusivos (como pegar o compilador da Intel ou talvez para algum chip dedicado ou apenas um RPi simples), o script de construção não deve se preocupar com isso ou precisa de qualquer mudança (o código pode, é claro, mas idealmente não deve nunca, já que o CMake pode dizer o que tudo é suportado por meio de definições) e o usuário pode fornecer seu próprio arquivo de conjunto de ferramentas personalizado para a construção usar.

EDIT: E nunca menospreze o apoio generalizado. Não consigo encontrar nada sobre o meson ser capaz de gerar arquivos de projeto para o KDevelop (o IDE que uso, que curiosamente usa o CMake como formato de construção, ocasionalmente uso o CLion no trabalho, ele também usa o CMake), onde quase todos os IDE saem ( até mesmo o Visual Studio!) pode abrir projetos CMake nativamente agora (além do CMake ser capaz de gerar projetos para a maioria dos IDE diretamente, se desejar).

@ OvermindDL1

Não é CMake não padrão absolutamente. O exemplo de código visa CMake 3.0, uma versão na qual CXX_STANDARD não existe. Você pode ver facilmente aqui que usa target_compile_features com cxx_std_ e o número do padrão. Esta é a nova e moderna maneira cmake de definir a versão padrão. set_target_properties é uma abordagem por alvo mais antiga.
Na verdade, o código exato retirado da documentação do CMake é

target_compile_features(mylib PUBLIC cxx_std_11)

No entanto, CXX_STANDARD não define o suporte libc ++ para clang, pois clang usa libstdc ++ por padrão no linux a menos que seja configurado (e nunca é configurado para usar libc ++ por padrão na maioria das distribuições de Linux, pois isso causaria erros de linker e problemas de ABI) . A única maneira de fazer isso neste momento é verificar se o compilador suporta -stdlib=libc++ e passá-lo para o compilador por meio de uma expressão geradora. Não há nada envolvendo variáveis ​​não expostas em relação a isso.

Além disso, não agradeço que você tenha descartado um comentário para fazer correções de um comentário que fiz meses atrás, especialmente considerando que estarei visando CMake em vez de Meson em minha próxima tentativa. Falta tato e, em minha opinião, nada acrescenta à conversa.

O CMake 3.0 é antigo o suficiente para não ser mais compatível (10 de junho de 2014). Ninguém deve estar executando nada menos do que o CMake 3.10 atualmente, embora seja preferível manter-se atualizado com o CMake 3.12 no momento.

E sim, o exemplo que você deu é totalmente contra (acho que até CGold menciona não fazer isso).

E sim, eu quis dizer target_compile_features. ^. ^;

No entanto, CXX_STANDARD não define o suporte libc ++ para clang, pois clang usa libstdc ++ por padrão no linux, a menos que seja configurado (e nunca é configurado para usar libc ++ por padrão na maioria das distribuições de Linux, pois isso causaria erros de linker e problemas de ABI). A única maneira de fazer isso neste momento é verificar se o compilador suporta -stdlib = libc ++ e passá-lo para o compilador por meio de uma expressão geradora. Não há nada envolvendo variáveis ​​não expostas em relação a isso.

Todas as cadeias de ferramentas atuais fazem isso muito bem, pelo menos com C ++ 14, pois é com isso que eu compilo (e alguns C ++ 17).

Além disso, não agradeço que você tenha descartado um comentário para fazer correções de um comentário que fiz meses atrás, especialmente considerando que estarei visando CMake em vez de Meson em minha próxima tentativa. Falta tato e, em minha opinião, nada acrescenta à conversa.

Peço desculpas, não percebi a data pois estava lendo o backlog (e há muito backlog aqui). Acabei de notar algo que parecia terrivelmente errado para qualquer tipo de sugestão moderna pelo que tenho visto há alguns anos e não vi nenhuma correção nos posts logo depois, portanto, queria que a informação incorreta não se propagasse. :-)

A única maneira de fazer isso neste momento é verificar se o compilador suporta -stdlib = libc ++ e passá-lo para o compilador por meio de uma expressão geradora.

No entanto, sim, esse é o trabalho do arquivo do conjunto de ferramentas, que nunca deve aparecer em um arquivo de construção, nunca .

Não há nada envolvendo variáveis ​​não expostas em relação a isso.

Eu estava apenas referenciando as variáveis ​​que são definidas e usadas em outros lugares em apenas um local, o que é recomendado no CGold, entre outros, por uma variedade de razões.

O CMake 3.0 é antigo o suficiente para não ser mais compatível (10 de junho de 2014). Ninguém deve estar executando nada menos do que o CMake 3.10 atualmente, embora seja preferível manter-se atualizado com o CMake 3.12 no momento.

Eles não deveriam, e ainda assim alguns lugares são. Para um motor de jogo que tenta se manter atualizado e com a tecnologia mais recente, ficar no CMake mais recente é bom. No entanto, estou mais do que ciente de projetos extremamente ativos presos em versões mais antigas, como 3.5 e, em alguns casos, 3.4. Na verdade, algumas bibliotecas C bem conhecidas ainda têm como alvo o CMake 2.8 (consulte: SDL2, libssh2, libgit2, etc.) É uma grande dor de cabeça para ter certeza.

No entanto, sim, esse é o trabalho do arquivo de conjunto de ferramentas, que nunca deve aparecer em um arquivo de construção, nunca.

Fazer essa suposição (que os arquivos do conjunto de ferramentas são bem escritos e cobrem todos os sistemas possíveis e todas as versões do CMake) é pedir problemas no atual ecossistema C ++ geral. Ao usar o clang, a opção de compilar para libstdc ++ ou libc ++ (especialmente quando usada por meio de uma chamada FetchContent ) deve ser fornecida pela biblioteca. CheckIncludeCXX e CheckCXXCompileFlag ainda são necessários até mesmo para alguns sinalizadores que não existem no GCC, mas existem no Clang (e vice-versa). O principal problema aqui é que as interfaces do compilador divergem muito e, em vez de os fornecedores perderem tempo para facilitar as opções de compatibilidade ou até mesmo discutir uma interface comum, esse comportamento é imposto a nós, o desenvolvedor, quando tudo o que queremos fazer é escrever código. Acredite em mim, ninguém neste planeta está mais chateado com o estado dos sistemas de compilação C e C ++ e gerenciamento de dependências do que eu, mas o pragmatismo para as bibliotecas existentes no CMake é necessário. O bom de mudar de um sistema de construção para o CMake é que podemos começar do zero com os melhores e mais recentes recursos. O problema se torna a estagnação do sistema de compilação porque ninguém quer tocá-lo (exceto para aquela alma corajosa que chutou os scripts de compilação de geração de código para scripts separados), mas algum trabalho seria necessário para garantir que não saia do controle (o que acontecerá porque ... quero dizer, é um sistema de construção. Eles sempre fazem)

Devo ser o único cara que realmente gosta de escrever scripts de construção, especialmente no CMake;).

Fazer essa suposição (que os arquivos do conjunto de ferramentas são bem escritos e cobrem todos os sistemas possíveis e todas as versões do CMake) é pedir problemas no atual ecossistema C ++ geral. Ao usar o clang, a opção de compilar para libstdc ++ ou libc ++ (especialmente quando usada por meio de uma chamada FetchContent) precisa ser fornecida pela biblioteca.

Essas coisas devem ser propriedades passadas para o conjunto de ferramentas sobre as quais o conjunto de ferramentas pode agir.

Assim como se você tiver uma configuração única, é inteiramente razoável incluir arquivos de conjunto de ferramentas, como, digamos, para uma compilação de android muito personalizada ou algo assim (embora o conjunto polly estendido de cadeias de ferramentas cmake tenha coberto quase tudo que eu precisei até agora).

O problema se torna a estagnação do sistema de compilação porque ninguém quer tocá-lo (exceto para aquela alma corajosa que chutou os scripts de compilação de geração de código para scripts separados), mas algum trabalho seria necessário para garantir que não saia do controle (o que acontecerá porque ... quero dizer, é um sistema de construção. Eles sempre fazem)

Este é realmente um ótimo ponto para escolher o CMake agora, ele tem um conjunto de padrões bem definidos para seguir que funcionam muito bem agora, depois de lidar com mais de uma década de experiência anterior, tanto boa quanto ruim.

Devo ser o único cara que realmente gosta de escrever scripts de construção, especialmente no CMake;).

Eu gosto disso em comparação com as alternativas, com certeza, embora eu tenha escrito nele por tempo suficiente para que faça sentido para mim, embora isso definitivamente não signifique que faria para todos. ^. ^;

Eu usei muitos sistemas de construção diferentes ao longo dos anos. O que fez mais sentido para mim recentemente é o CMake, mas posso definitivamente ver o apelo do SCons e como ele é flexível.

Mesmo que o SCons não seja perfeito (que sistema de compilação é?), Ele pode ser bom o suficiente.

• Ele fornece os recursos necessários?
• Quanta sobrecarga isso cria?

Se SCons pontuar "bom o suficiente" para ambos os pontos, mantenha-o.

Algum de vocês, propondo a substituição do SCons por outra coisa, realmente se esforçou para aprender como funciona o sistema de construção de Godot?

Como uma dica, é incrivelmente complexo e não acho que haja muitos (ou nenhum) projetos usando a construção CMake para tantas plataformas e permitindo ter vários destinos de construção configurados / compilados ao mesmo tempo da maneira que fazemos.

Todos os esforços daqueles que disseram "Eu irei transportar o sistema de construção de Godot para outra pessoa" falharam miseravelmente até agora quando percebemos a complexidade do que o SCons está cuidando.

Para mim, é de longe a melhor ferramenta para o trabalho. Nada está nem perto disso. Se vocês reclamam do tempo de compilação base (que é de apenas 4/5 segundos em um sistema de médio a alto com SSD), você realmente deve primeiro tentar entender tudo o que Godot faz ao compilar e ver como funcionaria no CMake ou qualquer outra coisa .

Eu dei uma olhada. Não estou convencido de que seja reversível no CMake ou em outro lugar. Mas também sou preguiçoso;). Veremos o que acontece.

Como alguém que fez o Bazel Port. Consegui chegar ao ponto em que o editor Godot começou sem ícones.

Tenho certeza de que o CMake pode chegar a esse ponto.

PS. O projeto concorrente mais próximo com grandes quantidades de plataformas é o Urho3d.

Reproduzi meu resultado bazel no cmake.

https://github.com/fire/godot/tree/cmake

Suponha que o Visual Studio 2017 esteja instalado.

git clone https://github.com/fire/godot.git -b cmake
scons p=windows
Modify platform/register_platform_apis.gen.cpp
#include "register_platform_apis.h"

void register_platform_apis() {
}

void unregister_platform_apis() {
}

Instale cmake

choco install cmake ninja -y
# Open visual studio command prompt amd 64 2017 native
# Go to godot source directory
cd ..
mkdir build
cd build
cmake ../godot -GNinja
ninja

Por favor, brinque com isso. O editor tem os mesmos problemas que a construção do bazel (sem ícones), mas você pode achar este exemplo útil.

Observação

• Os ícones funcionam a partir de 71175b45f819e7cc5e4368dbf3e42abdd19af542
• Visual Script e GDscript funcionam

@fire Obrigado por isso. Vejo muitos locais para melhorias que tornariam a manutenção desses arquivos CMake mais fácil (e o tempo gasto adicionando novos recursos ou sinalizadores de compilador). No entanto, posso lidar com o próximo fim de semana, com a programação pendente.

Excelente trabalho @fire. Fico feliz em ver que alguém aqui pode produzir algo em mais do que apenas um sistema de compilação: smile :

Ligeira atualização. Tive algum tempo de inatividade hoje para lidar com a construção do trabalho de suporte para strings de modelo e isso pode tornar a vida um pouco mais fácil, em vez de ter que processar strings, adicioná-los a uma lista e, em seguida, processar mais strings e adicioná-los a uma lista, etc. etc.

O ideal é que os scripts de geração de código possam ser executados como se fossem executáveis ​​sem o conhecimento da construção. Contanto que os arquivos apropriados fossem passados ​​para eles, estaríamos prontos para fazer a portabilidade completa para qualquer outro sistema de compilação.

@ slurps-mad-rips Extrair isso de seu sistema SCons é uma boa ideia, mesmo em SCons. Você pode desligar o GIL por ter muita lógica no processo e prejudicar o desempenho de construção. Ocasionalmente, isso pode levar a algumas condições de corrida de fechamento / abertura de arquivo ao compilar em paralelo (embora muitas vezes seja resolvido abrindo o arquivo em um contexto).

Olá a todos,

Vou usar este espaço para manter as pessoas atualizadas sobre a porta para o CMake. Se solicitado, farei uma edição separada e monitorarei as alterações lá, embora esta seja uma área agradável, visto que tem um grande acúmulo de discussões e acho que seria um desperdício perder tanto contexto.

Eu divago. Vou ter que fazer uma pausa na porta CMake na próxima semana enquanto participo de uma conferência, no entanto, você pode ver os esforços de minha tentativa de transferência inicial aqui . Lembre-se de que vou atirar para ficar 1: 1 com o branch master atual e, como tal, forçarei o push das alterações conforme elas vierem, para que possa manter um rebase. Conforme me aproximo da estabilidade, apresentarei uma solicitação de pull para manter os rebases mais fáceis de trabalhar, bem como para tornar mais fácil comentar as alterações ou fazer perguntas. Eu acho que esta porta para CMake não é apenas factível, mas no mínimo fará com que mais uma pessoa (eu) seja bem versada em como Godot é realmente construído e construído e eu posso ser capaz de colocar isso em palavras para que outros possam entender uma visão panorâmica do sistema de compilação. Essa porta também pode tornar o fluxo de trabalho de todos mais fácil no longo prazo, especialmente com lançamentos. Não vou mentir, misturar CONFIGURE_DEPENDS arquivos com o Ninja é realmente muito bom.

Uma última coisa, eu sugiro que todos vocês dêem uma olhada nos módulos auxiliares do

Você conseguiu atualizar para a versão 3.1 alfa mais recente? O alfa pode ser um bom alvo. Atualmente tentando a compilação.

O título desta edição é Considere mover o sistema de construção para Meson . Eu acho que é inapropriado ter uma discussão sobre o CMake aqui. A discussão sobre o CMake deve ter seu próprio problema. A comparação de Meson com qualquer outra coisa está bem.

@zaniar Tem havido muita discussão neste tópico sobre sistemas de construção em geral. Só porque o título não foi atualizado não significa que iremos criar um novo problema repentinamente e perder todo o contexto para discussão e começar tudo de novo. Acho que nos pedir para de repente jogar fora vários meses de discussões é impróprio.

@fire Tenho estado ocupado com o trabalho nas últimas semanas, tenho um grande prazo para sexta-feira e, depois disso, terei algum tempo para atualizar meu garfo. Eu tenho algumas mudanças localmente I esqueceu de empurrar para cima, mas eu não tenho tempo agora. (Entre esta porta de sistema de construção, meu fork do gnu m4, 15 propostas que estou escrevendo para a reunião de padrões C ++ em San Diego e CppCon na última semana do mês, estou absolutamente atolado e não tenho ninguém para culpar, Eu mesmo)

Sim, Meson foi o alvo da discussão original, mas acho que é natural que outros sistemas de construção tenham sido trazidos e discutidos desde então, e provavelmente faz sentido manter a discussão dentro desta questão aqui em vez de espalhá-la, como @slurps -mad-rips disse.

Eu concordo em mudar para CMake. Ele tem muito suporte com seus conjuntos de ferramentas. As compilações do Android, por exemplo, tornam-se muito fáceis em comparação com o que Godot está fazendo em seu arquivo SCsub, que parece 'impossível de manter' para mim.

Como um projeto de código aberto, Godot deve escolher soluções que sejam fáceis de manter e que os colaboradores tenham mais probabilidade de conhecer e para as quais possam contribuir.

Além disso, acho que isso é importante para a adoção do GDNative. Qualquer que seja a ferramenta de construção usada, deve haver um exemplo ou projeto padrão com script de construção facilmente modificável que ofereça suporte à construção para todas as plataformas, incluindo iOS, Android, etc.

Além disso, os módulos normais devem poder ser compilados como bibliotecas compartilhadas. Isso está relacionado ao # 19486 para que o mecanismo possa ser separado em vários componentes para download.

Na verdade, estou lidando com isso. Não empurro minhas mudanças há algum tempo porque estou ocupado com a CppCon, a próxima reunião de padrões C ++, e estamos lançando um lançamento na próxima semana no trabalho. Basta dizer que não tive muito tempo para finalizar a porta, mas a maior parte do meu tempo vou ser gasta copiando os scripts Python que geram código C ++ daqui para frente. Espero retomar o trabalho no meu porto neste fim de semana. No momento, estou avaliando se devo adquirir automaticamente dependências de terceiros e aplicar patches armazenados no repo ou não. Uma pergunta que tenho para os desenvolvedores principais é o quão abertos eles estariam para quebrar todos os repositórios third_party fora do repositório principal e em seus próprios repositórios na organização. Estou confiando bastante em FetchContent em meus próprios projetos e, no momento, desejo poder fazer isso para essas dependências de terceiros que foram ligeiramente bifurcadas. Isso também me permitiria trabalhar em cada um para limpar seus arquivos cmake enquanto também fazia alterações incrementais no repositório principal, uma vez que cada biblioteca de terceiros é portada.

Além disso, devo observar que estou tentando modularizar o próprio mecanismo também, para que esses componentes possam ser tecnicamente atualizados separadamente um do outro, se alguém quiser. Isso pode eliminar o problema mencionado por @chanon .

Por último, estou adicionando suporte para algumas ferramentas de construção adicionais para os desenvolvedores principais, se elas forem encontradas no sistema. Coisas como clang-format, clang-tidy, ccache ou sccache, distcc, clang-check, desinfetante de endereço, ubsanitizer, desinfetante de thread, etc. Estes são principalmente linters (e podem fazer algumas pessoas explodirem com os avisos e vários erros que detectamos), mas eles serão opcionais para serem ativados. No mínimo, o uso de sccache ou ccache trará algumas melhorias na construção ao alternar entre as construções e vice-versa. Esperar pelo lançamento do CMake 3.13 seria bom, pois isso resolveria parte do trabalho desastroso no qual tive que contar, mas o importante é que estou configurando-o para que o fluxo de trabalho de "introdução" atual seja para ainda executar pip install via Python 3.5 ou posterior, entretanto, estará dentro de um virtualenv para que as pessoas não tenham que mexer com o ambiente de seu sistema. (Isso também permitiria que outros experimentassem o uso de bibliotecas Python adicionais como dependências para vários scripts de geração de código e não precisariam se lembrar de desinstalá-los posteriormente)

De qualquer forma, desculpe pela atualização repentina de informações, despeje todos vocês. Estou empenhado em terminar este porto, mas a vida atrapalhou recentemente 😅

Estou confiando bastante no FetchContent em meus próprios projetos e, no momento, desejo poder fazer isso para essas dependências de terceiros que foram ligeiramente bifurcadas.

Você também pode usar o Hunter e fazer um repositório de código específico para o godot (um repositório git especial, como no github, por exemplo) e acessar todas as dependências dessa forma, uma vez que lida com a construção, cache, etc ... conforme necessário e corretamente (ou submeta todas as dependências ao repositório de pacotes Hunter 'principal' e apenas use-o diretamente). Hunter é apenas um único arquivo cmake (HunterGate.cmake) e uma chamada para ele para adquirir as informações do repositório de pacotes (seja oficial ou personalizado).

Um pedido humilde: o tópico de comentários deste problema ficou enorme - alguém que o acompanha seria capaz de resumir a discussão geral até agora em um comentário (e talvez pudesse ter um link para a postagem inicial de

Olá pessoal. Estou planejando usar Godot como meu próximo motor para fazer um pequeno jogo.

Eu vi essa conversa e como uma pessoa que tem experiência em CMake e Meson (e autotools, tup, plain make, waf, SCons, tentando projetos completos em todas essas ferramentas ...) eu queria dar meu feedback.

Os sistemas que usei mais intensamente foram Autotools, CMake e Meson. Tenho usado Meson e CMake nos últimos anos, uma vez que já descartei todos os outros sistemas de compilação em configurações de produção.

Profissionais do cmake

• Geradores de projetos maduros se você se preocupa com o Visual Studio (acho que Meson o suporta bem hoje em dia, mas não tentei recentemente) e especialmente XCode (com certeza está faltando mais aqui).
• Adoção mais ampla, mais suporte em IDEs
• Adoção mais ampla -> mais fácil de obter contribuições (embora Meson seja uma brisa de aprender, devo dizer)

Profissionais de Meson

• muitos alvos úteis por padrão: desinfetantes, builds de unidade de graça, cabeçalhos pré-compilados de graça, cobertura de graça ...
• a documentação chuta o traseiro da documentação do CMake: http://mesonbuild.com/
• Achei a compilação cruzada muito mais fácil
• Meson tem uma maneira óbvia de fazer cada coisa

Qual eu escolheria? Eu escolheria Meson se a compilação cruzada fosse intensiva e você se preocupasse com tempos de compilação rápidos (builds unitários e cabeçalhos pré-compilados são suportados por padrão).
Eu consideraria o CMake, pois é o padrão e as contribuições talvez sejam importantes para a equipe. Eu escolheria Meson pessoalmente, mas isso é apenas uma opinião pessoal, já que acho a ferramenta apenas melhor e isso economiza meu próprio tempo (script CMake, manipulação de espaço, expressões de gerador, etc ... Estou olhando para você).

Desculpe por essa autopromoção descarada abaixo, mas acho que o contexto está implorando por isso.

Eu tenho uma pequena série de artigos sobre Meson mais ou menos básico aqui se alguém estiver curioso (4 artigos):

• https://medium.com/@germandiagogomez/getting -started-with-meson-build-system-and-c-83270f444bee
• https://medium.com/@germandiagogomez/getting -started-with-meson-in-c-part-2-58150354ff17
• https://medium.com/@germandiagogomez/getting -started-with-meson-in-c-part-3-70b9bc419957
• https://medium.com/@germandiagogomez/getting -started-with-meson-part-4-8bceec6149e1

Tenho uma resposta (um pouco desatualizada) sobre sistemas de compilação no StackOverflow:

https://stackoverflow.com/questions/5837764/autotools-vs-cmake-for-both-windows-and-linux-compilation/24953691#24953691

Apenas meus dois centavos :)

@germandiago Esse é um ótimo artigo - venho acompanhando este assunto há um tempo e seria maravilhoso se eu pudesse trabalhar com godot + CLion, que infelizmente é apenas CMake.

Sim, a maioria dos IDEs modernos são apenas CMake e / ou algum sistema de compilação personalizado e / ou 'chamadas brutas' que perdem muitos recursos. CMake realmente se tornou padrão, seja merecido ou não.

@dorkbox se eu conseguir essas mudanças nas quais estou trabalhando, você definitivamente poderá trabalhar em um fluxo de trabalho CLion (cmake + ninja).

@germandiago

Na verdade, sou amigo agora (mais ou menos 😛), do autor do meson desde CppCon 2018. Ambos terminamos no mesmo papel para a próxima reunião sobre módulos intitulados "Lembre-se do Fortran", e irei apresentar seu artigo na referida reunião (é na próxima semana, na verdade!), e também estávamos no mesmo painel de sistemas de construção na CppCon.

Eu adoraria usar o Meson. Se você ler mais adiante no tópico, tentei uma porta de meson, mas as coisas estavam muito integradas ao Scons na época. Ainda estou retirando os scripts de geração de código atuais para serem scripts 'executáveis' separados para que, se, no futuro, uma mudança para o Meson não esteja fora de questão. No entanto, é um trabalho lento, e comecei a escrever alguns modelos jinja para ajudar na geração de código, de forma que os scons possam ser totalmente descartados. Dito isso, embora meu fork público esteja desatualizado, o que tenho em casa está um pouco mais à frente (e sincronizado com um fork privado). Infelizmente, o trabalho atrapalhou e San Diego, infelizmente, vai 'roubar' mais do meu tempo. Depois disso, no entanto, devo estar livre para remover alguns dos experimentos locais que tenho em minha bifurcação particular e, finalmente, voltar no trem godot cmake. Estou comprometido em garantir que uma solicitação pull completa possa ocorrer sem causar uma grande interrupção no processo de fluxo de trabalho atual.

(Como um aparte: obrigado a todos pela paciência que vocês tiveram enquanto eu trabalho nisso. Eu sei que já faz um tempo desde que comecei, mas eu represento meu empregador para o órgão nacional dos EUA para o comitê de padrões C ++ agora, então minha agenda tem estado um pouco mais completo ultimamente, especialmente porque abordamos tópicos importantes como módulos, corrotinas e intervalos)

Sim, a maioria dos IDEs modernos são apenas CMake e / ou algum sistema de compilação personalizado e / ou 'chamadas brutas' que perdem muitos recursos. CMake realmente se tornou padrão, seja merecido ou não.

Uma possível ferramenta útil para usar méson com IDEs:

https://github.com/prozum/meson-cmake-wrapper

Isso faz com que o IDE pense que está usando o CMake, mas na verdade está usando o meson nos bastidores.

Alguns antecedentes: fui um grande defensor do CMake por muitos (10?) Anos, mas me apaixonei pelo méson no ano passado ou assim. Meson parece ter sido escrito com a intenção de ter os recursos úteis do CMake enquanto conserta / evita muitos dos aborrecimentos do CMake. Um obstáculo que estou enfrentando atualmente para adotar o meson em um projeto é o suporte IDE. Acabei de descobrir a ferramenta acima, então talvez isso ajude.

Todo e qualquer sistema de construção tem suas principais falhas, mais do que isso, não há razão para mudar isso do ponto de vista técnico, seja scons, autotools, cmake, meson ou qualquer que seja o make vs ninja de sua religião. Acho que seria ótimo fechar todos os outros bugs de alteração do sistema de compilação como uma duplicata deste.

<reduz> iFire: no, you did not, all you did was build it but did not port any of the dozens of custom scripts that generate code
<iFire> reduz: the other person worked on the little python script generation on her branch
<iFire> so they directly imported the python env
<iFire> it's workable
<reduz> iFire: that is what everyone said that attempted it, and failed :P
<reduz> there are too many things in there

Prove reduz errado @ slurps-mad-rips :).

Gorila de 800 libras na sala que ainda não foi mencionado. Uma das reivindicações de Godot à fama é a compatibilidade entre plataformas. Deve seguir-se que qualquer sistema de construção com potencial para migração deve estar disponível e testado em todas as plataformas que Godot visa. Quem está por trás de tal migração deve estar inclinado a testá-la em todas as plataformas suportadas, ou pelo menos fazer parte de uma equipe que está fazendo isso. Caso contrário, eu consideraria tal movimento contrário à filosofia de Godot e geralmente apenas uma má ideia.

@lazybullfrog Tenho acesso a cerca de 5 máquinas separadas para desktop e vários dispositivos móveis. Parte do meu porte para o cmake é garantir que haja conjuntos de ferramentas do cmake disponíveis para todas as plataformas atuais.

@ slurps-mad-rips É um daqueles Haiku? Se não, estou disposto a ajudar no teste. Obrigado.

Parte do meu porte para o cmake é garantir que haja conjuntos de ferramentas do cmake disponíveis para todas as plataformas atuais.

Não se esqueça também de que, se você precisar de conjuntos de ferramentas cmake para uma plataforma, provavelmente há um pré-construído em https://github.com/ruslo/polly e, se não houver, você deve fazer uma RP. :-)

@ slurps-mad-rips Como está indo? Percebi que você atualizou o código em 14 de janeiro. Tentei compilar no Windows, mas não encontrei pkgconfig.

O @fire life decidiu lançar algumas bolas curvas no meu caminho e eu tive que cuidar delas. Coisas pessoais, infelizmente. Tenho me concentrado no trabalho e finalizado a biblioteca IXM que estou usando para reduzir a quantidade de trabalho que seria copiado para o godot. Felizmente, estou tirando férias em uma semana (estou indo para Kona para a reunião WG21 ISO neste trimestre neste fim de semana), então terei algum tempo livre para trabalhar nisso e (com sorte!) Terei uma versão funcional para macOS, Linux e Windows soon ™. Android e iOS, seguidos por FreeBSD e Haiku (desculpe @lazybullfrog , embora você seja mais do que bem-vindo para testar mais cedo / frequentemente) serão minha próxima prioridade depois disso.

A maior parte do trabalho / bloqueador até agora foi extrair os scripts Python em ferramentas "instaláveis" que são separadas dos Scons e executadas como processos. A captura real de dependências, configurações, etc. ficou mais fácil em comparação.

@ slurps-mad-rips, a vida me lançou algumas bolas curvas também. Talvez devêssemos começar um time de beisebol. 😂

Felizmente, uma dessas bolas curvas desde que comentei pela última vez foi um Xeon de 8 núcleos com 32 gb de RAM com Haiku e FreeBSD instalados. Talvez em breve eu consiga algum tempo para ajudar a testar os dois.

Na verdade, estou em êxtase por essas duas plataformas estarem recebendo atenção. Ansiosos para testar em breve.

Eu acho que é razoável ter vários sistemas de construção. Talvez um sistema de construção oficial que seja bem suportado e os outros fornecidos na base do "você descobrir". Os usuários desejarão usar seu próprio sistema de construção independentemente, então por que não agrupar seu trabalho em um só lugar?

Eu estaria disposto a contribuir com uma porta Bazel se as coisas correrem assim.

Eu acho que é razoável ter vários sistemas de construção. Talvez um sistema de construção oficial que seja bem suportado e os outros fornecidos na base do "você descobrir". Os usuários desejarão usar seu próprio sistema de construção independentemente, então por que não agrupar seu trabalho em um só lugar?

Como empacotador Linux, vi centenas de projetos com vários sistemas de construção. Eu vi alguns que tinham vários sistemas de construção disponíveis. Eu nunca vi um em que não fosse uma bagunça completa, especialmente quando os sistemas de construção alternativos foram contribuídos por contribuidores "por favor, adicione o CMake, é tão legal" pela primeira vez que então desapareceram do projeto, e os mantenedores não se preocuparam em atualizá-lo.

Não há valor algum em apoiar várias buildsystems, e eu não irá fundir qualquer PR indo nessa direção. Sou um dos principais mantenedores do sistema de construção e definitivamente não quero ter o fardo de manter outros alternativos sempre que precisarmos mudar algo.

Atualmente, temos um sistema de construção que funciona para todos e é bem suportado, sem intenção de mudar. Se alguém realmente deseja investigar outras opções, fique à vontade para, e se o resultado final também funcionar para todos, puder ser bem suportado e fornecer valor agregado sem grandes inconvenientes, nós o consideraremos.

Se alguém _realmente_ deseja investigar outras opções, sinta-se à vontade para, e se o resultado final também funcionar para todos, puder ser bem suportado e fornecer valor agregado sem grandes desvantagens, nós o consideraremos.

Isso é o que tenho feito com minha porta CMake. Atualmente, uma alteração no-op ou de um único arquivo em scons leva mais de 10 segundos na minha máquina atual (que tem 64 GB de RAM, processador comparável, etc.) Com o ninja + cmake, todo o processo de configuração + geração leva menos tempo, e o ninja a compilação termina em menos de 0,2 segundos em uma compilação autônoma (no Windows, onde iniciar um processo é caro). Também posso usar a ferramenta sccache do mozilla, se estiver instalada, e isso tem sido extremamente útil para editar as partes do codegen / executar uma compilação regenerada do zero para garantir que nada dependa do meu ambiente local.

a maior parte do meu tempo foi gasta extraindo os scripts de geração de código em scripts python que poderiam ser executados por conta própria. Se essa fosse a única coisa fundida em godot, meu tempo gasto nisso não teria sido um desperdício total. Ele também resolve o hack run_in_subprocess que existe atualmente para resolver problemas em janelas com paralelização.

Acabei de voltar de minha viagem e consegui trabalhar um pouco. No momento, ainda preciso copiar alguns arquivos de uma execução manual de scons, mas tenho eliminado as fontes geradas com o passar do tempo. Os cabeçalhos license.gen.h e method_bind.inc são atualmente meu maior alvo, mas estou levando alguns dias para lidar com o jetlag + trabalho antes de abordá-los.

(também vou copiar @fire, já que ele está interessado neste progresso há um tempo)

Pela minha experiência, Meson fica totalmente confuso ao construir o Android no Windows, simplesmente não consigo fazer funcionar para compilar uma das bibliotecas de terceiros que o utiliza (libepoxy). E eu acho que está muito ligado a coisas concretas do compilador.

Tudo o que desejo é um sistema de construção que possa gerar arquivos de projeto e arquivos de banco de dados separadamente do comando de construção.

Cada vez que eu verifico um novo branch com grandes alterações nos arquivos, tenho que executar o Scons na linha de comando para regenerar meus arquivos vsproj, o que também faz com que uma compilação completa ocorra de qualquer maneira. No Scons, pelo que tenho visto, não há nenhum tipo de estágio de geração de projeto. É também por isso que ele não oferece suporte à geração de bancos de dados de compilação prontos para uso nas ferramentas do clang.

Atualmente, a única solução viável para codificar Godot no Windows (IDE) é com o Visual Studio, caso contrário, esteja preparado para usar apenas um editor de texto.

Scons é maravilhoso e tudo mais, mas quando eu tenho um threadripper de 12 núcleos e 128 gb de ram e tenho que esperar mais de 12 segundos no Windows para compilar uma única mudança de linha (a maior parte disso é pensamento do Scons), fica um pouco chato.

Mas a verdadeira desvantagem do Scons (e esta pode ser minha preguiça em pesquisar) é que não consigo compilar arquivos cpp individuais. Ser capaz de compilar arquivos cpp individuais sem construir o projeto inteiro é um grande impulsionador da produtividade e verificador de sanidade.

Não são apenas mudanças de linha que levam tempo, até mesmo descobrir se há algo para construir leva tempo ...

Executando do git-bash:

$ time scons -j24 num_jobs=24 vsproj=true platform=windows
scons: Reading SConscript files ...
Configuring for Windows: target=debug, bits=default
 Found MSVC version 14.2, arch amd64, bits=64
YASM is necessary for WebM SIMD optimizations.
WebM SIMD optimizations are disabled. Check if your CPU architecture, CPU bits or platform are supported!
Checking for C header file mntent.h... no
scons: done reading SConscript files.
scons: Building targets ...
[Initial build] progress_finish(["progress_finish"], [])
[Initial build] scons: done building targets.

real    0m16.082s
user    0m0.000s
sys     0m0.030s

Se você deseja construir apenas um único arquivo de destino, especifique-o na linha de comando

scons -j24 num_jobs=24 vsproj=true platform=windows <path  to targetfile>/targetfile.obj

Só queria acrescentar que a versão mais recente do CMake está adicionando alguns dos recursos ausentes que as pessoas mencionaram anteriormente como razões para não usá-lo.
Compilações do Unity: https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html
Cabeçalhos pré-compilados: https://cmake.org/cmake/help/latest/command/target_precompile_headers.html

@Nosliwnayr Ambos foram suportados por addons por muitos anos, eles foram bem testados e desejados agora para serem incluídos. Essas nunca foram razões para não usar o CMake, já que você é capaz de fazer os dois no CMake há muito tempo.

@bdbaddog
eu não entendo, eu tenho que especificar cada arquivo manualmente? o que essa coisa .obj faz?
como faço para aplicá-lo a todo o projeto? ele recompila arquivos individuais automaticamente?

Espero que os tempos de compilação possam ser otimizados ainda mais, ser capaz de compilar código c ++ quase que instantaneamente sem truques seria ótimo - depois de ver como o godot compila rápido, estou realmente lutando para voltar ao motor irreal 4 (compilando-o , levou 45 minutos, mas agora o motor de alguma forma ficou mais inchado e leva até 60 minutos, o que é uma loucura)

quer dizer, acho que godot tem potencial para compilar ainda mais rápido, e eu mesmo substituiria o sistema de compilação, mas tenho 0 experiência, então literalmente não teria ideia do que fazer

@Nosliwnayr
podemos evitar cabeçalhos pré-compilados? eu acho que eles são um lixo completo, basta mantê-lo simples

eles também tornam os projetos de compartilhamento muito mais irritantes, e isso é um inchaço sem fim, com muitas desvantagens em minha mente - mas ei, se alguém os usou de forma eficaz, eu estou bem, mas para mim eles parecem um truque sujo, em vez disso de uma verdadeira otimização, e eu não gosto de truques baratos para ser honesto

depois de usar o motor irreal 4, estou cansado de 20 GBs de besteira pré-compilada, só acho que não valem a pena, tem que haver um sistema menos estúpido (o motor 4 irreal levou até 60 - 80 GBs para mim, nada legal)

se Godot seguir nessa direção, presumo que os desenvolvedores perderam a cabeça

inferno, foda-se, eu prefiro que eles fiquem nos scons, se isso evita a bola de insanidade do motor 4's irreal, eu acho que a abordagem mais inteligente seria melhorar os scons, em vez de substituí-los por completo por um traseiro quebrado novo sistema de compilação, quando o atual funciona ... mais ou menos

Eu acho que o esforço mental necessário, a fim de empurrar em um sistema totalmente novo, é muito maior do que apenas melhorar o que já temos, e o novo compilador pode acabar quebrando funcionalmente por meses

Eu com certeza não vou reclamar se isso for feito, mas com um componente de motor tão crítico, você praticamente tem que ir all-in, não há como voltar depois que isso mudar

@ RaTcHeT302 - A linha de comando especificada é se você deseja compilar explicitamente apenas um único destino (neste caso, um arquivo objeto) (e, claro, os arquivos dos quais ele depende)

Na verdade, se todas as pessoas reclamando sobre problemas com SCons contribuíssem para ajudar a corrigi-los, em vez de sugerir a troca de um sistema de compilação complicado por outro mais brilhante ... bem, muitas dessas preocupações seriam corrigidas.

@bdbaddog Scons não gera arquivos de construção de estágio intermediário. Ele executa a etapa de "dependência do projeto" na mesma etapa em que compila e não podem ser separados.

É como dizer ao CMake para gerar os arquivos do projeto todas as vezes antes de usar sua ferramenta de compilação, seja MSVC, ninja-build, make, llvm, escolha seu veneno.

Se eu mudar de branch git, não posso atualizar o visual studio sem executar uma compilação de linha de comando scons para regenerar os arquivos .vsproj e .sln adequados - e quase sempre limpo as alterações de branch de compilação, uma vez que tive problemas no passado.

Esses arquivos intermediários não são apenas para construção, eles podem ser usados ​​por analisadores estáticos e outros projetos também.

Embora eu concorde que cmake não é perfeito (eu não gosto tanto) e prefira a flexibilidade do python, cmake tem a melhor integração e suporte de todas as ferramentas de construção disponíveis.

Ao converter meu fork para CMake, a maior parte da complexidade estava nos arquivos de geração de código. A ideia de que a construção é complicada é uma falácia. A construção não precisa de scons porque é complexa. É complexo porque usa scons.

Dito isso, a razão de eu interromper o trabalho é porque me encontrei com os desenvolvedores líderes no GDC em 2019 (no encontro do GitHub) e eles disseram que não têm absolutamente nenhuma intenção de mudar para algo mais usável, citando que preferem fazer a compilação inteiramente no Linux e, de fato, pelo que vi, eles estão violando o EULA que a Apple exige que aceite para instalar ferramentas de compilação para compilação cruzada.

A mentalidade dos responsáveis ​​é muito "os fins justificam os meios" e não parece haver qualquer preocupação em tratar a construção como um software, e em vez disso, Godot a trata como uma série de scripts que produzem uma construção.

Não estarei contribuindo com as mudanças que fiz na geração de código para godot (apesar de ser mais legível e rápido), e desisti totalmente desse mecanismo e segui em frente com minha vida. Estou muito mais feliz se for honesto. O motor já tem um débito considerável de tecnologia e vejo isso sendo um problema em cerca de 3 anos, especialmente porque o comitê de padrões C ++ está trabalhando em um relatório técnico de ferramentas (estou envolvido nisso e tenho pressionado por coisas como arquivos de opções sendo padronizados até certo ponto, mas é apenas um relatório técnico, então algumas pessoas irão divergir dele).

É uma pena também. Minha compilação CMake foi capaz de detectar um monte de erros de análise estática que levaram a toneladas de problemas e são facilmente resolvidos, mas estou muito cansado de ter discutido com os desenvolvedores sobre isso no GDC para arquivar bugs ou mesmo tentar consertar eles. Minha energia e minha saúde mental são melhor gastas em outro lugar.

Não há nenhum mundo onde os scons serão capazes de lidar com o design dos próximos módulos C ++ 20, por mais que eu tenha gritado que isso quebrará muitas ferramentas. Ele não pode lidar com o rastreamento de dependência para isso e exigiria que ele tivesse uma etapa de pré-varredura, o que tornará o rastreamento de dependência ainda mais lento.

Por último, vou sugerir às pessoas que não tentem melhorar uma ferramenta que só pode aceitar pequenas alterações. Os Scons precisariam de uma reescrita completa do zero e de um grande número de alterações importantes para obter as melhorias que as pessoas buscam.

Sugiro que este problema seja encerrado porque a discussão sobre a mudança do sistema de construção foi respondida no GDC 2019, mas os líderes nem acham que vale a pena perder tempo comentando sobre esse assunto, o que eu acho que mostra o quanto eles se preocupam com a ergonomia de desenvolvimento.

Eu sinto que se o sistema de compilação existente fosse 100% convertido em um modo plug and play, não haveria razão para os desenvolvedores não mudarem.

Construir apenas no Linux é inútil. Ter um motor de jogo que não roda no Windows irá deter qualquer desenvolvedor sério de jogos.

Eu gostaria de ter a impressão de que os desenvolvedores de jogos se preocupam o suficiente em mudar o sistema de construção para satisfazer seus usuários.

Uma das razões pelas quais deixei o Unreal é que o motor é feito principalmente para a criação de jogos Blueprint / front-end. Criar ferramentas em módulos c ++ é extremamente doloroso e complexo no Unreal.

Até agora, em Godot tem sido decentemente agradável. Tornar as compilações C ++ mais rápidas seria uma grande vantagem para a comunidade.

IIRC eles usam o Wine para rodar as ferramentas de compilação do MSVC. Ainda não muda seu ponto, e eu concordo.

Construir apenas no Linux é inútil. Ter um motor de jogo que não roda no Windows irá deter qualquer desenvolvedor sério de jogos.

Godot sempre foi compilável em muitas plataformas, não apenas no Linux ...

IIRC eles usam o Wine para rodar as ferramentas de compilação do MSVC. Ainda não muda seu ponto, e eu concordo.

As compilações oficiais do Windows são compiladas usando MinGW; não usamos WINE para rodar MSVC no Linux.

@marstaik - se você alternar as compilações e executar scons apenas para gerar os arquivos do projeto MSVS, deverá ser capaz de especificar esses arquivos como o destino e não ter que fazer uma compilação completa.

então tente:

scons <path to created MSVS project file>/VSPROJECTFILENAME (replace with actual paths and file name which are generated)

O SCons deve ser capaz de fazer isso sem fazer uma compilação completa e também deve fazê-lo corretamente sem que você precise fazer uma limpeza primeiro.
(Aliás. Eu sou o mantenedor do projeto SCons)

@bdbaddog eu tive que adicionar vsproj = True a esse comando, mas parece que funcionou

Do godot src:
scons -j24 godot.vxcproj num_jobs=x vsproj=true

Editar: por algum motivo, você precisa adicionar o sinalizador -j também ...

@bdbaddog eu tive que adicionar vsproj = True a esse comando, mas parece que funcionou

Do godot src:
scons -j24 godot.vxcproj num_jobs=x vsproj=true

Editar: por algum motivo, você precisa adicionar o sinalizador -j também ...

Muitos desses sinalizadores não são SCons originais, mas parte da maneira como vários pacotes (Godot, neste caso) implementam seu sistema de construção com SCons.
Que bom que você encontrou uma maneira!

Por que usar o SConstruct e insistir em não mudar para outro sistema de construção ???

@tjysdsg A discussão acima resume isso muito bem: ligeiramente_smiling_face:

Vou encerrar isso porque deixamos claro ao longo dos anos que não temos nenhuma intenção a priori de alterar o sistema de construção. Estamos satisfeitos com o SCons e qualquer uma de suas deficiências pode e deve ser avaliada individualmente, tanto no uso do nosso próprio SCons quanto no upstream, se for devido ao próprio ferramental.

Mudar para um sistema de construção "mais frio" só por fazer não vai acontecer. A grande maioria dos contribuidores principais fica feliz em usar o SCons e é o que agora conhecemos melhor. Mudar para um novo sistema de construção tem um custo de implementação e aprendizado, e não foi provado até agora que valeria a pena.

Resumindo, uma mudança no sistema de construção não é algo que aceitaríamos de novos contribuidores. Tem que vir de dentro, e todos os colaboradores principais devem ver isso como uma mudança positiva para que faça algum sentido. Não mudaremos o sistema de construção apenas para agradar aos novos usuários que tentam construir Godot a partir da fonte e de alguma forma não gostam que eles tenham que digitar scons vez de cmake ou meson que estão habituados. Também não aceitaremos tentativas de introduzir um novo sistema de construção opcional - por experiência própria, sei que isso só pode levar a inconsistências, bugs e diferenças de saída.

É claro que estamos abertos para mudar nossas mentes se ganhos claros puderem ser listados (e mostrados com uma prova de conceito funcional) que superem os custos de alteração do sistema de construção, mas a partir de hoje e após dois anos de discussão aqui, eu pessoalmente não não vejo o incentivo.

@ slurps-mad-rips disse isso bem.

É complexo porque usa scons.

e

Meu build CMake foi capaz de detectar um monte de erros de análise estática que levaram a toneladas de problemas e são facilmente resolvidos

É totalmente nojento que o CMake não seja levado a sério, posso pensar em muitos motivos para abandonar o SCons, mas ESPECIFICAMENTE o fato de o CMake encontrar erros que o Scons não encontra faz com que "valha a pena" usar outra coisa.

Mudar para um sistema de construção "mais frio" só por fazer não vai acontecer

CMake não é "legal", é o padrão. Se você realmente o usasse, entenderia imediatamente o porquê.

É claro que estamos abertos a mudar nossas mentes se ganhos claros puderem ser listados (e mostrados com uma prova de conceito funcional) que superem os custos de alterar o sistema de construção

Não estou convencido de que alguém esteja disposto a mudar de ideia. Novamente, @ slurps-mad-rips mostrou ganhos claros, e ela até fez todo o trabalho ... Já está feito.

É uma vergonha, representando a postura oficial da equipe de Godot, desconsiderar completamente seus esforços para melhorar o processo de desenvolvimento.

Eu entendo perfeitamente a sua dor, mas ainda concordo com os outros - toda a construção
sistemas têm seus
prós e contras e geralmente o mesmo. Raramente há alguma razão técnica
para mudá-lo.
Quanto a razões políticas, eles não farão nada de bom a longo prazo
corre. Todo mundo
prefere algo diferente. De qualquer forma, ninguém impede ninguém de fazer garfos
para qualquer
motivos, então acho que este é tão bom quanto qualquer outro.

Na sexta-feira, 21 de fevereiro de 2020 às 13h38, dorkbox [email protected] escreveu:

@ slurps-mad-rips https://github.com/slurps-mad-rips disse isso bem.

É complexo porque usa scons.

e

Minha construção CMake foi capaz de detectar um monte de erros de análise estática que
levaram a muitos problemas e são facilmente resolvidos

É nojento que CMake não seja levado a sério, eu posso
pense em muitas razões para abandonar SCons, mas ESPECIFICAMENTE que CMake encontra
erros que o Scons não encontra faz com que "valha a pena" usar outra coisa.

Mudar para um sistema de construção "mais frio" só por fazer não vai acontecer

CMake não é "legal", é o padrão. Se você realmente o usasse,
entender imediatamente o porquê.

Claro que estamos abertos a mudar de ideia se ganhos claros puderem ser listados
(e mostrado com uma prova de conceito funcional) que superam os custos de
mudando o sistema de construção

Não estou convencido de que alguém esteja disposto a mudar de ideia. Novamente,
@ slurps-mad-rips https://github.com/slurps-mad-rips mostrou ganhos claros,
e ela até fez todo o trabalho ... Já está feito.

É uma vergonha, representar a postura oficial da equipe de Godot,
desconsiderar completamente seus esforços para melhorar o processo de desenvolvimento.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/godotengine/godot/issues/16014?email_source=notifications&email_token=AAABPU2PBIEK6PFKQ2LDTHLRD6VKVA5CNFSM4ENJ6NN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMSI4JY#issuecomment-589598247 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAABPU746R4YFHAI73Z57RTRD6VKVANCNFSM4ENJ6NNQ
.

@dorkbox - cmake encontrou erros de análise estática? ou foi a saída do banco de dados de compilação do cmake executado pelas ferramentas de análise estática do llvm que os encontrou?

@bdbaddog , @ slurps-mad-rips fizeram o trabalho nisso e seria melhor perguntar a ela. (Acho que seria o resultado da análise estática do llvm, mas não fui eu que fiz o trabalho de construção via cmake)

@slapin

Raramente há qualquer razão técnica para alterá-lo.

Que tal ferramentas de análise estática e suporte a recursos de linguagem moderna?

@bdbaddog @dorkbox Eu simplesmente liguei o clang-tidy para procurar coisas como "retornando referências a locais não estáticos" e "estouro de buffer" via CMake. Também executei a verificação do clang em algumas coisas e obtive mais alguns resultados. Eu consegui fazer com que include-what-you-use rodasse também, e ele encontrou algumas inclusões de cabeçalho desnecessárias.

Dito isso, eu realmente não "terminei" a porta cmake. A parte que nunca foi portada foi todo o trabalho que fiz ao tentar alterar os scripts Python atuais que simplesmente chamam f.write em algum arquivo para gerar um arquivo JSON. Consegui remover muito dessa lógica e substituí-la por um gerador de template baseado em jinja2 genérico. Isso também resolveu um hack que o scons atual constrói nas janelas onde inicia um script como um executável.

No entanto, eu esperava manter a paridade com o build do scons e, pelo menos, obter minhas alterações na geração de código mesclada. Isso não aconteceu porque os scripts Python usados ​​para gerar arquivos de origem estão mudando constantemente, e mantendo essas alterações em sincronia com a minha templatização do jinja2 foi um exercício de frustração.

Dado o "não" muito enfático e duro que recebi dos desenvolvedores líderes no encontro GDC GitHub, decidi que não queria mais contribuir com godot. Minhas mudanças foram indesejadas, não são desejadas e são apáticas à opinião de qualquer outra pessoa sobre o assunto. Não estarei contribuindo para godot, nem para qualquer bifurcação de godot. Desejo a todos sorte em tentar convencer os desenvolvedores líderes sobre o assunto, mas é como falar com uma parede de tijolos. Inabalável, imóvel e apático ao sofrimento de todos neste tópico.

Portanto, se o SCons puder cuspir o banco de dados de compilação que é inserido nas ferramentas llvm, isso também poderá ser feito a partir do SCons.

Portanto, se o SCons puder cuspir o banco de dados de compilação que é inserido nas ferramentas llvm, isso também poderá ser feito a partir do SCons.

Parece que existe a falácia do custo irrecuperável acontecendo com o SCons. Por que não usar algo que é mais fácil, simplificado e já faz parte das ferramentas de compilação existentes, como o cmake?

No site da scons:

Quando comparado com scons, CMake é:

• Mais rápido
• Requer menos código para tarefas comuns
  
  
  
  • Indiscutivelmente mais estável
  
  
  • Suporta saída para projetos como Code :: Blocks, Xcode, etc. que scons não
  
  

@dorkbox - Sou o co-gerente do projeto SCons. Estou apenas de olho na funcionalidade desejada.

Os últimos lançamentos e o próximo tiveram melhorias de desempenho.

Além disso, temos relações públicas para geração de arquivos ninja e alguns membros da comunidade têm ferramentas de compilação de banco de dados. Portanto, é provável que alguns dos problemas sejam resolvidos (pelo menos parcialmente, se não totalmente) na próxima versão.

Não estou ciente de nenhum problema de estabilidade afetando o projeto godot que não tenhamos abordado. Se houver algum pendente, por favor nos avise.
(Entre em contato por meio de: https://scons.org/contact.html)

Não tenho certeza se cmake realmente requer menos código para tarefas comuns, estou interessado em uma comparação razoável.

Bem, o que mais me surpreende com scons é a incapacidade de gerar
GNU make makefile. Falta de ninja - posso viver com isso.
Também manuseio de utilitários de compilação cruzada como conjuntos de ferramentas CMake e autotools
recursos de compilação cruzada é um forte ponto fraco do cmake.
O resto está ok porque eu não sou uma pessoa IDE. Meu IDE é o ambiente UNIX.

No domingo, 23 de fevereiro de 2020 às 22h05 William Deegan [email protected]
escreveu:

@dorkbox https://github.com/dorkbox - Sou o co-gerente do projeto SCons.
Estou apenas de olho na funcionalidade desejada.

Os últimos lançamentos e o próximo tiveram desempenho
melhorias.

Além disso, temos RP para geração de arquivos ninja e alguma comunidade
os membros têm ferramentas de compilação de banco de dados. Portanto, alguns dos problemas são prováveis
a ser tratada (pelo menos parcialmente, se não totalmente) na próxima versão.

Não estou ciente de quaisquer problemas de estabilidade afetando o projeto godot que nós
não abordou. Se houver algum pendente, por favor nos avise.
(Entre em contato por meio de: https://scons.org/contact.html)

Não tenho certeza se o cmake realmente requer menos código para tarefas comuns, eu estaria
interessado em uma comparação razoável.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/godotengine/godot/issues/16014?email_source=notifications&email_token=AAABPU5TQQFET5RS2JDRY7TRELCHDA5CNFSM4ENJ6NN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMWEOMI#issuecomment-590104369 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAABPU6UHPX3HJTWPAFTPATRELCHDANCNFSM4ENJ6NNQ
.