Godot: Considere mover el sistema de compilación a Meson u otro sistema de compilación

Por lo que entiendo, las herramientas del sistema de compilación deben proporcionar:

• Compilación cruzada (compila en todas las plataformas de destino posibles desde la misma plataforma de host).
  
  
  
  • Por "posible" me refiero a que el host lo permite (por lo que macOS e iOS solo son posibles en una máquina Mac y desde Linux con OSXCross).
  
  
• Una forma de generar archivos (traducción de PO, clases de sombreado de GLSL, datos de documentación de XML).
  
  
  
  • SCons sabe que los archivos generados son dependencias, por lo que cambiarlos desencadena una reconstrucción de los archivos relevantes. Esto también debería tenerse en cuenta.
  
  
• Múltiples objetivos y opciones dentro de los objetivos (target = debug / release_debug / release, arquitectura como x86 o ARM, 32 o 64 bits).
• Opciones para personalizar la compilación / habilitar objetivos adicionales (envoltorio gdnative, sin pegamento mono, habilitar / deshabilitar: módulos, controladores, características obsoletas, etc., configurar bibliotecas para compilar estáticamente usando el código incorporado o usar las bibliotecas del sistema, para cada uno individualmente).

No conozco a Meson, pero si proporciona todo lo anterior, debería estar bien (si no me olvidé de algo). Por supuesto, alguien tiene que pasar por el dolor insoportable de reescribir el sistema de construcción en Meson y luego demostrar que las herramientas y los tiempos de construcción son efectivamente mejores para Godot que para SCons.

Tenga en cuenta que algunas dependencias de terceros requieren que se compile un parche con Godot. Noté que Wrap tiene un soporte de parche, pero parece que el parche debe estar disponible en algún lugar para descargar, mientras que creo que es más fácil de administrar si todavía son parte del repositorio. Además, algunos de ellos requieren indicadores de compilación especiales que no deben aplicarse a toda la compilación.

Creo que tal prueba de concepto sería muy valiosa porque

• nos da una mejor idea si el nuevo sistema de compilación maneja todo lo que necesitamos y qué tan bien lo hace
• nos da datos concretos en lugar de abstractos para discutir

Para el segundo punto, esto significa que podemos ver la diferencia en la velocidad de compilación para Godot , podemos ver cuánto más fáciles (o más complejos) se vuelven nuestros scripts de compilación, y podemos comparar las diferencias más fácilmente para tomar una decisión en lugar de hacerlo bien informado. conjeturas basadas en lo que creemos que podría ofrecer.

-

Ahora, personalmente, tengo que decir que no estoy ni a favor ni en contra de esto, pero creo que hay más fruta madura que perseguir en lugar de (¿o antes?) Cambiar todo el sistema de compilación. Especialmente en este momento crítico, donde se necesitan tantas manos como sea posible para asegurarse de que 3.0 y los primeros parches estén en la mejor forma posible. Pero si queremos mejorar el sistema de compilación, miraría los tiempos de compilación de CI y la molestia de la situación de compilación Mono. (Creo que estos son en Akien 's TODO / lista de aggrievances?)

Además, las compilaciones paralelas con errores en Windows apestan, pero eso es más a nivel personal, sería bueno si se corrigiera.

TL; DR:

• Estoy de acuerdo en que faltan documentación / recursos de SCons, que los scripts de compilación son fáciles de usar Python contrarresta un poco eso, en mi opinión
• Como colaborador nuevo, el sistema de compilación de Godot fue uno de los menos molestos de configurar, muy poco tiempo para la primera compilación exitosa
• Prefiero ver el esfuerzo invertido en mejorar 3.0 / 3.1 tanto como sea posible y tal vez pensar en esto una vez que sean estables
• Mejores tiempos de compilación de CI y compilaciones Mono más fáciles podrían ser más importantes

Mis opiniones. :)

Creo absolutamente que lanzar 3.0 y centrarse en las siguientes versiones (3.0.1, 3.1) debería tener prioridad sobre esto, para que conste.
Sé por qué a la gente no le gusta trabajar en sistemas de compilación (ya que en realidad es solo para el beneficio de otros desarrolladores / usuarios finales particularmente conocedores de la tecnología, lo cual no es poco importante, vale la pena facilitar la vida de los desarrolladores y colaboradores , pero en última instancia, la felicidad de los usuarios finales es el objetivo) y existe todo esto del "costo de oportunidad", es decir. cuando el tiempo dedicado (o perdido / desperdiciado, dependiendo de a quién le pregunte) en mejorar el sistema de compilación podría dedicarse a mejorar el proyecto en sí. (A menos que seas como yo y no puedas trabajar en el lado C ++ de las cosas de todos modos).

Y, en última instancia, SCons realmente "simplemente funciona", lo que para la mayoría de los desarrolladores probablemente será lo suficientemente bueno, así que si bien esto es algo que espero que suceda eventualmente, no voy a aguantar la respiración durante 3.1 o incluso 3.2, si es que consigue suficiente apoyo como para empezar a trabajar en él.

Dicho todo esto, podría poner en marcha el POC a finales de esta semana en mi bifurcación, para aquellos que estén dispuestos a seguir el progreso en eso (y probablemente ayudarme, ya que no tengo una gran cantidad de experiencia escribiendo sistemas de compilación), pero lo más probable es que no abra una solicitud de extracción para esto durante un tiempo.

Realmente no encuentro que SCons sea lento, y su flexibilidad (que aprovechamos muchísimo) probablemente no tenga comparación con ninguna otra cosa. SCons también está extremadamente probado, me parece que nunca arruina una construcción.

Honestamente, a menos que alguien se ofrezca como voluntario para reescribir todo el sistema de compilación (no solo una prueba de concepto) y demuestre que es más simple (mucho menos código) o mucho más rápido , ni siquiera consideraría nada más, ni siquiera un poco.

Ahora, personalmente, tengo que decir que no estoy ni a favor ni en contra de esto, pero creo que hay más fruta madura que perseguir en lugar de (¿o antes?) Cambiar todo el sistema de compilación.

Eso no es realmente perjudicial para este cambio. Quiero decir, la mayoría de los colaboradores de Godot trabajan en su tiempo libre y trabajan en lo que quieren. Para el caso de @NullConstant , parece que es "hacer esto o no hacer nada" (sin decir que no quiere arreglar las cosas, solo que es más difícil trabajar con la base de código C ++ real y buscar errores en algo desconocido), así que hacer esto es algo bueno en general.

Además, el argumento de "hay mejores cosas que hacer" es la forma de no hacer nada en mi opinión. Por supuesto, no se fusionará nada hasta que estemos seguros de que no romperá las cosas y no se hará cerca de un lanzamiento. Estoy de acuerdo en que hay cosas más importantes, pero eso no significa que no se pueda empezar.

La cuestión es que alguien que esté trabajando en esto probablemente tendrá que hacerlo solo. Por supuesto, los desarrolladores centrales pueden responder preguntas específicas, pero más que eso no sucederá. Por eso nunca se consideró que SCons fuera reemplazado: nadie hasta ahora quería ensuciarse las manos. Como dije antes sobre Bullet: alguien tiene que hacer que funcione y demostrar que es posible y mejor, de lo contrario, nos mantendremos en el status quo.

Aunque creo que SCons es lento. No es muy lento, pero cosas como el estado de progreso y el caché hacen que las reconstrucciones sean más lentas (el uso de E / S de disco para leer desde el caché lo hace más lento), así que los desactivo al reconstruir. Se necesita un poco para empezar a hacer cosas, después de eso es bastante rápido.

No sé si Meson será significativamente más rápido, pero si alguien está dispuesto a intentarlo, no estoy en contra.

Oh, claro, si alguien se toma el tiempo para hacerlo y demuestra que es una mejora lo suficientemente grande como para justificar el cambio, estoy totalmente de acuerdo :)

Como dije, no estoy realmente equipado para lidiar con la búsqueda de errores de C ++ o agregar nuevas características en ese frente, así que estoy de acuerdo con hacer esto en su lugar.

Supongo que esto me da a mí (y / oa cualquier otra persona que trabaje en esto en el futuro) un objetivo doble y bastante limpio que alcanzar:

• conseguir que Godot compile con Meson en cualquier forma para empezar
• Hágalo tan fácil como lo es SCons en este momento, posiblemente incluso más (mejorando las velocidades)

Y supongo que la velocidad de SCons no es terrible (la mayor parte del tiempo del proceso de compilación proviene de la vinculación y compilación reales de todos modos, por lo que la desaceleración de la sobrecarga del sistema de compilación es probablemente algo insignificante), pero ciertamente podría mejorarse, y ofrecer Meson como alternativa podría ser esa mejora. Ya veremos.

El mayor problema probablemente sea reemplazar los scripts de compilación de Python para generar código automáticamente como los sombreadores, no parece que meson tenga una característica como esa.

y ofrecer Meson como alternativa podría ser esa mejora. Ya veremos.

No debería ser una alternativa, o lo adoptamos si es claramente mejor, o ni siquiera lo ofrecemos. Tener que admitir dos sistemas de compilación es una locura.

Bien, eso es justo.

Comenzaré a piratearlo en los próximos días / semanas, veré si esto va a alguna parte y si realmente vale la pena realizar un esfuerzo (incluso si termino siendo la única persona que trabaja en eso todo el tiempo).

Informaré si obtengo algo presentable (como un punto de referencia).

Aunque, no meson, haré una prueba en las próximas semanas para ver qué se necesita para construir godot bajo bazel para Windows 64 bit bajo msvc.

Bazel es otro sistema cuya ventaja es una descripción de compilación más corta y compilaciones más rápidas. También es mantenido por Google, por lo que no va a ninguna parte.

De todos modos, no puedo verificar eso, pero es muy probable que el 99% del tiempo computacional dedicado a construir Godot se gaste en el compilador. Entonces, incluso si la sobrecarga del software de construcción no fuera ninguna, esto conduciría a una disminución del 1% del tiempo de construcción. Incluso una disminución del 5% no valdría la pena, a menos que permita menos código y más confiabilidad (o si se demuestra que estoy equivocado :)).

Para la velocidad de construcción sin procesar de un clon limpio, dudo que tenga una diferencia significativa. Pero puede ser significativo si considera las velocidades de reconstrucción. SCons siempre reconstruye muchas cosas que no se cambiaron cuando realizo una nueva confirmación (especialmente OpenSSL y Bullet, que son bibliotecas grandes y tardan un poco en compilarse).

Como dije antes, SCons es lento para comenzar (toma unos segundos antes de comenzar a compilar). Si está construyendo toda la fuente, eso es insignificante, pero si solo cambió una línea y está compilando para probar, puede mejorar significativamente el flujo de trabajo (lo que en mi opinión es lo que más importa en el sistema de compilación: ayudar a las personas que trabajan con el código) . Por lo tanto, 5s disminuidos en una construcción de 10 minutos es irrelevante, pero 5 segundos disminuidos en una reconstrucción de 10 segundos es una mejora importante.

Pero estoy de acuerdo en que cualquier cambio en este sentido debería probarse mucho para demostrar que funciona. Como dijo @reduz , SCons nunca estropeó una compilación, y eso es algo a considerar.

Bazel es otro sistema cuya ventaja es una descripción de compilación más corta y compilaciones más rápidas. También es mantenido por Google, por lo que no va a ninguna parte.

Incluso hay una categoría creciente de Wikipedia de "cosas que Google descontinuó". :)

@mhilbrunner No, todavía se mantiene https://github.com/bazelbuild/bazel

Su punto era que solo porque Google lo hizo, no significa que estará disponible por mucho tiempo.

Dado que hemos adoptado C # para el desarrollo de juegos, también podríamos probar algo como Cake . Sin embargo, no lo he probado yo mismo, así que me interesa saber qué piensas al respecto. Por un lado, al menos, los scripts se ejecutarán más rápido que con Python.

Dado que hemos adoptado C # para el desarrollo de juegos, también podríamos probar algo como Cake .

No estoy seguro de si requerir una instalación Mono para compilar Godot es una buena idea, considerando que Godot es principalmente un proyecto C ++ y se puede compilar sin soporte C #.

El nivel de rendimiento ofrecido por Meson o CMake (con el generador Ninja) debería ser más que suficiente para los propósitos de Godot.

@Calinou probablemente tengas razón, aunque parece que todos se han

Editar:

Para aclarar, requerir que se instale Mono Framework para construir Godot no me suena tan mal, ya que los llamados motores de juegos AAA requieren mucho más espacio en disco:

• Godot <50 MB
• Godot con soporte Mono (<50 MB) + Marco Mono (~ 350 MB) = ~ 400 MB
• Irreal ~ 20GB
• Unidad ~ 10GB
• CryEngine ~ 8GB

Además, podríamos codificar el soporte Mono en el editor de forma predeterminada y tener algo de lógica para detectar si se admite o no el scripting C # en tiempo de ejecución, y solicitar el marco Mono o las plantillas de exportación adecuadas.

Me encanta CMake, y meson se ve genial, pero tiendo a estar de acuerdo con este artículo: http://www.rojtberg.net/1481/do-not-use-meson.

Estoy muy interesado en hacer el juego de pies para mover a Godot a Meson. Lo único que actualmente me impide contribuir a Godot (y usarlo) son Scons. Tuve que usarlo hace años, y nunca he tenido una experiencia de desarrollo incremental más dolorosa en toda mi vida.

El artículo vinculado anteriormente tiene muchos argumentos de paja, argumentando que CMake ya existe y deberíamos usar eso. Los archivos de compilación de Meson son extremadamente fáciles de leer y usan una sintaxis cercana a la de Python. La conversión puede ser rápida. Lo que estoy publicando en este hilo es, si se hizo el juego de pies, ¿se consideraría una solicitud de extracción para la fusión?

Lo que estoy publicando en este hilo es, si se hizo el juego de pies, ¿se consideraría una solicitud de extracción para la fusión?

Se considerará, pero debe demostrarse que es ventajoso sobre SCons.

Una vez que considere CMake solo otro sistema de compilación y no el estándar de facto, terminará con demasiadas opciones. ¿Por qué mesón sobre SCons? ¿O bazel / buck también son herramientas decentes? Pero el mayor argumento que tengo a favor de CMake son las herramientas creadas para respaldar ese ecosistema. Bases de datos de compilación de Clang, soporte para empaquetado en múltiples sistemas operativos, etc. Las únicas desventajas válidas que he escuchado son la mala sintaxis y los documentos, pero eso no es lo suficientemente fuerte como para cambiar mi posición al respecto.

¿Por qué mesón sobre SCons?

Meson genera archivos ninja, que es mucho más rápido para el desarrollo incremental. Además, en Windows, no es necesario realizar ningún tipo de manipulación de ruta de Visual Studio. Meson funciona fuera de la caja. El uso de meson sobre scons reduciría gran parte de la sobrecarga de las ventanas de orientación, especialmente para aquellos que desean usar Visual Studio (de los cuales, debo señalar, meson puede generar proyectos como CMake)

¿O bazel / buck también son herramientas decentes?

Dado que bazel y buck están escritos en Java (una dependencia que godot tiene solo si apuntará a Android, e incluso entonces uno podría usar técnicamente solo el NDK), yo diría que son una dependencia principal para todos. usuarios. Python ya está en la lista de dependencias, y puedes instalar meson (y ninja) fácilmente a través de un rápido pip install meson

Bases de datos de compilación de Clang

Meson admite esto de forma predeterminada, ya que esta es una función predeterminada integrada en ninja

soporte para empaquetado en múltiples sistemas operativos

Meson también tiene soporte para esto y depende en gran medida de pkg-config cuando sea apropiado

Las únicas desventajas válidas que he escuchado son la mala sintaxis y los documentos

Meson tiene una sintaxis muy similar a la de Python, que se basa en variables, objetos y funciones integradas. En mi opinión, escribiendo

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

vs

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

es mucho más fácil, especialmente dado que cmake a veces distingue entre mayúsculas y minúsculas y otras veces no. Cuando comienzas a meterte en expresiones generadoras, puede volverse extremadamente 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)

El mesón equivalente se ve así:

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)

Creo que debería señalar, por cierto, que de todos los sistemas de compilación de C ++ que existen, Meson es el menos terrible . Los argumentos en contra de su uso tienden a ser la imagen de un cómic web, algunos señalan cómo CMake es el más utilizado, por lo que debería tratar con él, y "oye, al menos CMake no es autotools".

Pero sobre todo (y creo que esto es algo realmente importante, especialmente para aquellos que usan godot como gdnative), Meson admite encabezados precompilados de forma nativa. CMake no lo hace (y usar cotire para piratear la compilación puede causar más problemas de los que vale).

No puedo decirles cuánto esto podría acelerar la compilación para los usuarios nativos, pero será un impulso significativo en gcc y msvc (al menos, un aumento de rendimiento en msvc es inevitable). Agregue el uso de extern template para las cantidades muy pequeñas de código con plantilla que se encuentran en godot, y podría ver mejoras decentes en el tiempo de compilación, que son importantes para compilaciones iterativas e incrementales.

Meson genera archivos ninja, que es mucho más rápido para el desarrollo incremental.

Tenga en cuenta que CMake también puede generar archivos de compilación Ninja en lugar de los Makefiles tradicionales; esto se hace pasando -G Ninja a su línea de comando. Funciona bastante bien en la mayoría de los proyectos que he probado y es un poco más rápido en general (además, utilizará todos los subprocesos de la CPU de forma predeterminada).

Meson todavía gana en las comparaciones de rendimiento en bruto que he visto, pero esto definitivamente ayuda a cerrar la brecha entre el rendimiento de Meson y CMake.

Sí, sin embargo, CMake no instala ninja automáticamente y no es el generador predeterminado. La mayor parte del tiempo de CMake se dedica a configurar el proyecto, en mi experiencia, y aunque las versiones recientes de CMake han mejorado enormemente el rendimiento, no todos tendrán la última versión de CMake.

¡Bien, eso es bastante completo! Me alegra que tenga una buena idea de las características que valora en un sistema de compilación. Sigo pensando que debería haber un sistema de compilación estándar en el mundo C ++ en el que los proyectos puedan confiar. Solo desearía que meson fuera un transpilador de CMake en lugar de lo suyo.

Sigo pensando que debería haber un sistema de compilación estándar en el mundo C ++ en el que los proyectos puedan confiar.

Créame, nadie quiere esto más que yo. Me he convertido en una especie de duende de la basura del sistema de compilación e incluso di una charla sobre ellos en CppCon. Desafortunadamente (¿o afortunadamente?) Me preocupo mucho por los sistemas de construcción, casi hasta el punto de la obsesión. :)

Solo quiero decir esto, pero cada vez que hice una compilación larga de Godot en Windows, noté que Python tomaba constantemente> 15% de mi CPU. Dudo que sea lento para empezar.

¿Quién va a hacer un pequeño prototipo de motor godot construido con meson? Nunca llegué al punto de crear una pequeña prueba para bazel.

Una versión 2d de godot debería ser suficiente para probar con todas las opciones desactivadas.

El primer obstáculo que enfrenté fue core / make_binders.py. Este es el código autogenerado que usa godot.

Hice un prototipo inicial en el sistema de compilación Bazel, pero discutiré la configuración en otro tema. https://github.com/godotengine/godot/issues/18518

No tengo tiempo durante la semana, pero otros pueden expandir Bazel BUILD.

Lol, ¿cómo se involucró Bazel?

Dado que podría haber una oportunidad única para cambiar a un sistema de compilación diferente, ¿no deberíamos buscar las mejores opciones posibles? Por mi parte, estaría interesado en ver una tabla de comparación de Cake vs Bazel vs Scons, aunque debo admitir que no tengo experiencia con Cake para hacer el trabajo de pies para esas pruebas.

@rraallvv ¿te refieres a Cake o CMake?

@isaachier Mi mal, estaba hablando de www.cakebuild.net , debería haber sido más específico, lo siento.

¿No es solo para C #?

@isaachier Realmente no lo sé, todo este tiempo asumí que Cake era capaz de eso, al igual que SCons está escrito en Python y tiene soporte para C ++. Sin embargo, acabo de preguntar en su chat de gitter , volveré a publicar aquí la respuesta.

@rraallvv para el registro Creo que la idea de una comparación lado a lado de los principales sistemas de compilación es una gran idea. Esto es lo que encontré en línea que creo que es bastante imparcial (no escrito por los desarrolladores del sistema de compilación): 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.

Mi opinión personal:

• CMake : lenguaje bastante feo, pero ubicuo y prácticamente el estándar de la industria.
• SCons : estado lento, antiguo e IDK. Utiliza Python.
• meson : Nuevo y genial sistema de compilación basado en Python que no es increíblemente lento. La principal desventaja es la trayectoria. No está claro si esto será solo otra versión del sistema de compilación de la semana.
• Autotools : Antiguo, sin soporte de herramientas (es decir, bases de datos de compilación para soporte de autocompletado de Clang o análisis estático). No es compatible con Windows. Evite a toda costa.
• bazel : un administrador de paquetes / sistema de compilación de Google integrado en uno. No agrega mucho sobre CMake con un complemento como Hunter . Además, el software de Google tiende a centrarse en lo que necesita Google, no en el público en general. Demasiado nuevo para medir la trayectoria a largo plazo.

Intento impulsar CMake siempre que tengo la oportunidad porque quiero un estándar de facto para C ++ y CMake tiene la mayor "participación de mercado" en este momento.

@isaachier Gracias por compartir esa información, estoy impulsando C # ya que no hay un sistema de compilación que admita secuencias de comandos en C ++, puede sonar tonto pero no sé por qué alguien no lo ha hecho todavía, por ejemplo, este C ++ REPL podría usarse para un sistema de construcción si uno quiere pasar al siguiente nivel y terminar el debate sobre cuál es mejor, más rápido, etc.

No entiendo. C ++ probablemente sería un lenguaje de compilación terrible. La lentitud tiene más que ver con el núcleo del sistema de compilación interno AFAIK, no con los detalles del lenguaje de secuencias de comandos utilizado.

@isaachier Supongo que SCons es muy lento porque fue escrito en Python, pero si alguien se tomara la tarea de portar todo el sistema de compilación a C ++ y también lo hiciera compilar JIT scripts de C ++ para ejecutar esas compilaciones, sería mucho más rápido. Quizás lo mismo podría ser cierto para todos los sistemas de compilación que existen.

Es una buena idea, pero meson no se considera lento por la mayoría de las cuentas, sin embargo, está escrito en Python.

Dudo que meson sea un sabor de la semana, ya que el proyecto GNOME está abandonando las autotools en favor de meson.

Además, Scons es lento no porque esté escrito en Python, sino porque también ejecuta la compilación. Es un sistema de construcción directo, como make o ninja, pero también usa cantidades masivas de XML para las definiciones y una gran cantidad de su código es en realidad solo conversiones XSLT.

Meson, por otro lado, ejecuta sus scripts de compilación para generar un árbol de dependencias y luego lo descarga en un archivo ninja. Meson es rápido, porque ninja es rápido. Además, no todo es una cadena en Meson, como en CMake.

Por último, debo tener en cuenta que hay varios sistemas de compilación en desarrollo en los que podrá realizar scripts en C ++ (en realidad estoy escribiendo uno de ellos). Sin embargo, pedirle a godot que se mueva a un sistema de compilación que aún no existe ( y peor, que yo mismo estoy escribiendo) es un poco arrogante, en mi opinión no tan humilde;)

También quiero reiterar, bajo el flujo de trabajo de desarrollo actual, Python es una necesidad. También lo es mesón. Y eso hace que pasar a meson sea tan simple como llamar a la herramienta pip Python.

Estoy completamente de acuerdo @reduz en que

Como dijo @ slurps-mad-rips:

Scons es lento no porque esté escrito en python, sino porque también ejecuta la compilación

hombre scons:

scons admite la construcción de múltiples objetivos en paralelo a través de una opción -j que toma, como argumento, el número de tareas simultáneas que pueden generarse:
scons -j 4

Tengo una CPU con 8c16t, así que usar "scons p = x11 -j 18" es muy rápido para mí.
Es 10 veces más rápido que usar "scons p = x11" como configuración predeterminada "-j 1".
¿Alguien tiene una CPU de un solo núcleo en el año 2018?
Deje que su CPU funcione completamente.
Por favor inténtalo.

No todo el mundo tiene estas CPU grandes, pero lo que es más importante, meson (bueno, ninja) es mucho más rápido en las recompilaciones incrementales. Scons, de forma predeterminada, realiza una suma de hash MD5 para ver si un archivo ha cambiado. Godot utiliza la configuración de marca de tiempo MD5, lo que significa que solo aplicará un hash a un archivo si ha cambiado una marca de tiempo. Sigue siendo ridículo.

Supongo que la mejor manera de demostrar lo que es mejor es escribir uno nuevo y ver :)

Scons no es rápido para muchas personas, especialmente los usuarios de Windows que tienen problemas con cualquier cosa por encima de -j 1.

@ slurps-mad-rips depende del proyecto. Ninja parece exagerar demasiado su velocidad. Vea este artículo: http://david.rothlis.net/ninja-benchmark/. Parece que contar los archivos de origen es su mejor opción aquí. Si <20K no hará mucha diferencia.

@isaachier ese punto de referencia es entre make y ninja, no ninja y scons, así que tendrás que perdonarme si no quiero prestarle atención. ;)

Supongo que la mejor manera de demostrar lo que es mejor es escribir una novedad y ver :)

Estoy de acuerdo, no tiene sentido deshacerse de las bicicletas. Si tiene una opinión sobre un mejor sistema de compilación, impleméntelo y demuestre que es mejor. De lo contrario, esta es una discusión de opinión y no conducirá a ninguna parte. @fire ya ha hecho una prueba parcial con bazel: https://github.com/godotengine/godot/issues/18518.

@ slurps-mad-rips ya es un tema totalmente diferente, no SCons. Solo quise decir que make vs ninja no es una gran diferencia.

Ligera actualización: estoy renunciando a intentar pasar al mesón. Ha sido poco a poco y, si bien los archivos de compilación son un poco más fáciles de leer, mantenerse actualizado con el sistema actual es donde paso la mayor parte de mi (ahora raro y escaso) tiempo libre, en lugar de mover scons a meson.

En este momento, una gran cantidad de código y operaciones se colocan directamente en los scripts de scons y esto dificulta el cambio a otro sistema de compilación. En todo caso, diría que se debería dedicar tiempo a desacoplar los scripts de Python existentes que generan código a partir de scons, ya que esto haría que el cambio a otro sistema de compilación como meson, cmake o incluso bazel sea mucho más fácil.

Menos mal que se fusionó un parche para eliminar toda la generación de código. https://github.com/godotengine/godot/pull/17595 ¡ No te rindas!

Co-Gerente del Proyecto SCons aquí. Un par de notas:
1 - SCons está en desarrollo activo y desde nuestra migración a Github estamos viendo un aumento en la tasa de solicitudes de extracción.
2 - Hemos identificado algunas partes específicas de SCons que son responsables de aproximadamente el 50% del tiempo de compilación incremental nulo y estamos trabajando activamente para solucionarlo. (La funcionalidad Subst)
3 - Comenzamos a admitir Python 3.5+ (así como 2.7.x) con SCons 3.0
4 - Permítanme sugerir que en lugar de intentar migrar a N sistemas de compilación diferentes, contribuir un poco de tiempo para ayudar a mejorar SCons podría ser un uso más efectivo del tiempo del desarrollador.
5 - Identificamos y abordamos mediante la elaboración de perfiles algunos de los frutos más fáciles de mejorar en la mejora del rendimiento que se lanzó en 3.0.0 y 3.0.1. Si está utilizando una versión anterior, la compilación incremental nula puede ser un 5-15% más lenta. (asumiendo Python 2.7.x)

Como siempre, el proyecto SCons está listo y dispuesto a ayudar a los proyectos que usan SCons con los problemas que encuentran.

Algunas "estadísticas" para SCons y godot.

Usé (y todavía lo hago) un Q6600 que es una CPU de 4 núcleos de 2008 más o menos con 2.4GHZ (y un número de instrucciones por ciclo más bajo) que los procesadores que "todos" estamos usando hoy (i7s).

En Q6600, una compilación tomó entre 3 y 5 minutos (o más, pero el número exacto no es tan importante), de los cuales ~ 35-40 segundos fueron gastados por SCons analizando el árbol de dependencias y esas cosas (el trabajo de preparación) ... por lo tanto, el 80% del tiempo dedicado a ejecutar el proceso cl.exe (compilador MSVC) una y otra vez.

Por lo tanto, en cuanto al rendimiento y la optimización, a menos que SCons (python realmente, no SCons) tenga un sistema de llamada de proceso terrible que esté tomando más tiempo del que debería o que algunas otras herramientas no compilen un archivo por proceso (como SCons actualmente) y el 1 El proceso por un archivo de sobrecarga es significativo (no soy un experto en las funciones internas de cumplimiento de cl.exe y los gastos generales de inicio), la única optimización del rendimiento que produciría un sistema de compilación más rápido es probablemente en la construcción de la fase del árbol de dependencias y otros preparativos para las complicaciones .

Por lo tanto, estamos optimizando esos 35-40 segundos de una compilación de 5 minutos (en i7 ahora probablemente estamos optimizando un paso de configuración de un solo núcleo de 20 segundos a partir de una compilación de múltiples núcleos de 3 minutos).

Entonces, para recapitular, si no recuerdo mal, de 3 a 5 minutos es en realidad una compilación multinúcleo de 4 núcleos, mientras que una compilación de un solo núcleo toma alrededor de 10. Necesito volver a ejecutar mis pruebas ...

Entonces, "optimizar" SCons significa optimizar más o menos esos primeros 35 segundos de inicio de las compilaciones ...

Eso es en lo que respecta a las "optimizaciones" cuando se trata de SCons frente a otro sistema de compilación más rápido ... Es posible que la compilación real se pueda optimizar un poco al evitar llamar a un solo cl.exe para cada archivo obj, pero eso solo si la sobrecarga del proceso es significativa (me temo que el HDD siempre será el cuello de botella de E / S real allí (y no la CPU), que no se puede evitar / mitigar sin un SSD)

Todos estos párrafos anteriores consideran una "construcción completa". Dicho esto, SCons "hace trampas" si todo ya está construido y pasa sus comprobaciones de consistencia de mano dura, por lo que si cambia un solo archivo, en realidad compilará un "solo archivo" y luego vinculará todo de nuevo, haciendo una "compilación completa" en algo de una construcción incremental). Sin embargo, esto requiere esos 35-40 segundos de cálculo previo del árbol de dependencias completo ...

Entonces, una "compilación incremental" es de alrededor de 45 segundos en mi computadora anterior, y cuando era un novato hace 2 años pensé que estaría vinculado a la CPU, pero en realidad, podría estar vinculado a IO (verificando varios miles de archivos en el disco duro ) para un barrido de dependencias completo / reconstrucción de árbol ... Entonces, si está vinculado a IO, ningún "sistema de construcción más rápido" resolverá ese ...

Mi idea hackear de hace 2 años era intentar adjuntar un "observador" del sistema de archivos a SCons, hacer que SCons se ejecutara y recompilara un solo archivo modificado (y sus dependencias, eso es automático), y luego simplemente vincular todo de nuevo ... aunque hoy me doy cuenta de que la vinculación probablemente ejecutaría un barrido de dependencia completo ... dicho esto, el barrido / reconstrucción del árbol de dependencia se puede eliminar con una opción y luego SCons usará su árbol de depósito en caché ... lo que ahorra alrededor de 15-20 segundos del paso de precomputación de 35 segundos (los primeros 15 segundos parecen inevitables) aunque eso puede no garantizar una compilación "perfecta" siempre como lo hace SCons (aunque eso podría no ser importante para compilaciones incrementales en desarrollo ... si decides que la velocidad es una compensación digna).

Ahora tengo suficiente conocimiento de que probablemente podría piratearlo a través de npm y npm watch ... u otro sistema con el que no estoy familiarizado actualmente ... Pero eso es para más adelante, y cuando tenga tiempo (no actualmente).

Esto se está haciendo un poco largo, así que lo terminaré aquí, pero el objetivo de estos párrafos fue brindarle información "estadística" en lugar de desanimar a cualquiera (siga adelante si le gusta trabajar en sistemas de compilación), como a mí mismo me gustó. arreglando algunas cosas en los SCons de Godot. Espero que alguna información les haya sido útil.

Si desea replicar / rehacer mis estadísticas, simplemente navegue por los documentos de SCons hasta que active la información estadística (cosas de temporizadores) y / o encuentre una manera de desactivar la resolución de dependencias (esos primeros 20 a 30-35 segundos de "precomputación" ) ...

O para una solución un poco menos manual, la información de depuración del temporizador ya debería estar presente (editar: es probable que no, alguien hizo lo que parece una actualización dulce para la generación del proyecto vs, este párrafo podría ser información obsoleta) en el proyecto VS automatizado generado por SCons (al final del archivo SConstruct) ... puedes encontrar información sobre cómo generar un Proyecto VS en el "Tutorial de compilación de Windows" en el sitio web de godot. Luego puede ejecutar SCons desde VS, creo que el proyecto generado probablemente aún debería funcionar, aunque no lo he probado en Godot 3 ... Es una opción, pero seguir scons a un> log.txt también es otra opción (etc.) ...

Esperamos que alguien haya encontrado útil esta información.

@Griefchief Solo para aclarar un poco las cosas, creo que no estamos tratando de optimizar los tiempos de compilación completa, ya que estos están dominados por el tiempo del compilador de todos modos. En cambio, queremos optimizar las compilaciones incrementales donde solo se cambia un solo archivo fuente.

De hecho, la "compilación incremental nula" (en realidad no es necesario reconstruir nada, pero los scons aún necesitarán procesar todo el árbol de dependencias para garantizarlo) es el caso en el que estamos trabajando.

Algunos perfiles han señalado algunas ineficiencias en el procesamiento de las líneas de comando (que deben hacerse para cada objetivo para asegurarse de que no hayan cambiado). La mayor parte de eso es la lógica Subst (). Este es un código complicado y hasta ahora se ha implementado de una manera más simple y segura, pero no terrible de manera eficiente.

Otro punto caliente de tiempo es la lectura y escritura de los archivos sconsign, actualmente implementados con cpickle y siempre leídos y escritos como un todo. Tenemos algunas ideas sobre cómo acelerar y / o hacer más incremental. De todos modos, mire los lanzamientos futuros para ver las mejoras.

En una nota al margen, puede probar MSVC_BATCH para ver si eso acelera sus compilaciones de Windows:

MSVC_BATCH
Cuando se establece en cualquier valor verdadero, especifica que SCons debe realizar la compilación por lotes de archivos de objeto al llamar al compilador de Microsoft Visual C / C ++. Todas las compilaciones de archivos de origen del mismo directorio de origen que generan archivos de destino en un mismo directorio de salida y se configuraron en SCons utilizando el mismo entorno de construcción se compilarán en una sola llamada al compilador. Solo los archivos fuente que han cambiado desde que se crearon sus archivos objeto se pasarán a cada invocación del compilador (a través de la variable de construcción $ CHANGED_SOURCES). Cualquier compilación en la que el nombre base del archivo del objeto (destino) (menos el .obj) no coincida con el nombre base del archivo fuente se compilará por separado.

@ bojidar-bg sí, sí, en realidad también estaba hablando de compilaciones incrementales, gracias por el consejo: D

@bdbaddog Hola baddog, solo para tu información, de hecho escribí este gran comentario antes de ver tu comentario, así que, en realidad no se refiere a nada en tu comentario específicamente ... pero lograste mencionar algunos de los " preocupaciones "Tenía (información para otras personas en realidad) mientras ambos escribíamos nuestros comentarios al mismo tiempo ...

Y no quería enviarte un ping porque no quería "perder" tu tiempo: D, pero supongo que lo haré si paso más tiempo en godot build / scons en el futuro (planeo hacerlo, estoy muy ocupado))

¡Gracias por tu aporte aquí!

@bdbaddog BD, ya que está brindando apoyo, si puedo preguntar aquí:

Si adjunto npm watch al sistema de archivos (fuente de godot) y sé qué archivo exacto se ha cambiado, ¿me brindaría algún beneficio con SCons?

Ahora puedo ejecutar scons a través de npm watch y enviar el archivo a él ...

scons [opciones de godot] el / archivo / que / fue / cambiado.

esto obviamente recompilará ese archivo, probablemente evitando todo el árbol de depuración de Godot. ¿correcto? Entonces, el recorrido del árbol de depuración no tomará 20 segundos, pero menos de 1 problema, pero obtengo 1 archivo .obj actualizado (o más, depende de lo que cambie). ¿En realidad no pasará por todo el árbol de depósito de Godot para ese archivo? ¿Tengo una ventaja en un menor recorrido del árbol de depuración en este ejemplo (y posiblemente otras ventajas en la fase de precomputación que no se pueden obtener mediante la reutilización de la memoria caché del árbol de depuración, como menos archivos en general para revisar?).

Ahora, si tengo una ventaja, y si quisiera vincular todo de nuevo, ¿necesitaría un recorrido de árbol completo para una fase de vinculación "simple"?

Entiendo que este caso de uso podría no ser compatible actualmente con Scons (solo vincule todo nuevamente), pero estoy preguntando tanto desde un punto de vista práctico como teórico. Me doy cuenta de que el árbol de depuración en caché podría reutilizarse con esa opción de "no hacer árbol de depuración" (lo olvidé, han pasado dos años), y eso funcionaría para algunos casos de uso, y ese caso de uso no es ningún archivo nuevo agregado, correcto ? (npm watch podría alertarme sobre la adición de un nuevo archivo y luego podría hacer una actualización completa del árbol de depuración si detecto eso ... en otras palabras, empujar el "asegurar la consistencia del árbol de dep" de nuevo a un filewatcher como npm watch, automatizar escribiendo esa opción "usar caché de dependencia" realizada manualmente por el usuario en un programa como npm watch ... deje que el programa se preocupe por la coherencia, no por el usuario, y hágalo en "tiempo real", en el momento en que el usuario haya guardado un archivo, dando mucho más tiempo para que los scons hagan su trabajo)

¿Hay algo en mi idea que no funcionaría como una optimización (práctica y teóricamente), y tienes otras sugerencias (que no tienen que garantizar una compilación perfecta si algo como npm watch puede encargarse de las cosas, también está bien? )? ¿Puede aconsejarme por favor? ¡Gracias!

En resumen, el caso de uso es similar a este:

1) ejecute un observador de archivos como npm watch en el directorio fuente de godot
2) el usuario guarda / modifica un archivo antiguo
3) npm ejecuta inmediatamente scons para ese archivo.
4) si la compilación es exitosa, npm indica a los scons que ejecuten el vinculador y vinculen el ejecutable.

4.1) si se cobra el árbol de depuración (ya se ejecutó una compilación completa), npm puede indicarle al enlazador que se vincule en este punto con una versión en caché del árbol de depuración
4.1) si no se detecta un árbol de almacenamiento en caché, npm watch ejecuta una compilación completa de godot
4.2) si se detectó una invalidación de caché, como agregar un nuevo archivo, realice un recorrido completo del árbol de depuración (npm no usará la opción "usar árbol de depuración en caché" con scons).

Espero que esto haga que mi idea sea un poco más fácil de entender, por favor déjeme saber qué le pasa en este momento; D

PD: Creo que este es el comando que reduce 15 segundos de la compilación incremental nula 35, con sus consecuencias "obvias" ... Básicamente, quiero automatizar lo que se describe aquí (más o menos, + dejar que los scons sepan qué archivo exacto se modificó si eso lo ayuda de alguna manera (o podría ayudarlo)):

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

Así que algunas cosas aquí (sin ningún orden en particular, pero estoy usando números porque yolo

1) Las compilaciones nulas incrementales no son básicamente nada bajo ninguna herramienta que genere archivos ninja. Chrome tiene, AFAIK, una compilación incremental nula de menos de 2 segundos. Esto es una nota importante, ya que una caída de 35 segundos a 15 bajo un npm watch sigue siendo muy grande en comparación con una compilación Ninja basada en mesón o cmake. Ninja también hace lo mismo que hace Scons, ya que realiza una reconstrucción en caso de que cambie la línea de comando (make, por supuesto, no hace esto)

2) CMake implementó recientemente la capacidad de usar CONFIGURE_DEPENDS como argumento para el sistema global. Esto siempre se ha recomendado no porque herramientas como xcodebuild y msbuild históricamente (y actualmente) no han admitido la detección de cambios de directorio. Esto es, afaik, una cosa que Scons podría mejorar, pero no tengo ni el tiempo ni la paciencia para profundizar en el proyecto para implementar esto. Básicamente, cada sistema operativo actualiza un directorio cuando cambia su contenido, ya sea un archivo agregado, un archivo modificado o un archivo eliminado. Al realizar cambios incrementales, uno puede simplemente verificar qué directorios han cambiado y globalizar solo aquellos en una verificación de reconfiguración. Esto puede reducir el trabajo realizado, ya que no engloba todo el árbol, sino partes más pequeñas. Para proyectos pequeños esto está bien. Si esto beneficiaría a godot o no, requeriría algunas pruebas y eso es mucho trabajo para verificar si incluso ayudaría.

3) Si bien es bueno ver que Scons está recibiendo más atención, personalmente creo que es mejor para la comunidad en general que godot se mueva a un sistema de compilación más usado. No puedo pensar fuera de godot en ningún proyecto grande que use Scons. GNOME / GTK se movió recientemente a meson (omitiendo CMake), KDE ha estado en CMake durante bastante tiempo. Si bien es una evidencia anecdótica (y, por lo tanto, un sesgo de confirmación básico), conozco a varios desarrolladores de C ++ a quienes les gustaría probar godot pero que preferirían no tener que tocar scons nunca más. Eliminar las experiencias desagradables y, por lo tanto, el sabor amargo que queda en la boca de los desarrolladores es difícil, y sinceramente le deseo lo mejor al proyecto Scons. Pero sé que la comunidad de C ++ en general ya odia el tiempo de compilación prolongado. Las compilaciones nulas incrementales largas (o incluso las compilaciones incrementales largas de 1 archivo) son una pesadilla en el mundo moderno.

Tengo la intención de volver a intentarlo, pero podría apuntar a CMake para esto. Pasar de CMake a meson es muchísimo más fácil gracias a que meson tiene un script de conversión que puede hacer mucho trabajo. CMake podría facilitar un poco el manejo de las dependencias con el nuevo módulo FetchContent. Veremos cómo funciona. Diré que me alegro de que estos scripts de codegen se hayan movido a archivos separados. Usar CMake será bueno aunque solo sea porque pasar a un estándar C ++ diferente es tan simple como target_compile_features(<target> (PUBLIC|PRIVATE|INTERFACE) cxx_std_<number>)

Obviamente, cualquier cosa relacionada con el sistema de compilación va a ser polémica, pero intentarlo no puede hacer daño.

Para ser bastante honesto, (y esto podría parecer insensible) no tengo ningún deseo de profundizar en el proyecto Scons para mejorarlo. Tal vez después de 2020, cuando Python 2.7 esté oficialmente realmente muerto y el proyecto pueda avanzar a Python 3.5+, solo valdrá la pena investigarlo o mejorarlo, posiblemente con operaciones asíncronas. Hasta entonces, sin embargo, preferiría no tener que tocarlo.

Tal vez después de 2020, cuando Python 2.7 esté oficialmente finalmente muerto y el proyecto pueda avanzar a Python 3.5+, solo valdrá la pena investigarlo o mejorarlo.

Scons 3 es compatible con Python 3.5+: https://scons.org/tag/releases.html .

Realmente no entiendo cómo a uno le pueden desagradar tanto los Scons y el desorden de configuración que es CMake, donde incluso es difícil definir su propia configuración de compilación si es un usuario, es difícil entender cuáles son las opciones y sus tipos y qué son definiciones internas, solo me trajo dolor, y en realidad me sentí aliviado de que Godot no lo usara.

En cualquier caso, si cree que va a ser una mejor solución, continúe e intente, podría terminar cambiando mi vista sobre CMake.

donde es incluso difícil definir su propia configuración de compilación si es un usuario,

Si se pregunta eso, CMake se está utilizando incorrectamente. Todas las configuraciones de la cadena de herramientas deben estar en un archivo de cadena de herramientas y cualquier configuración específica del proyecto se pasa a través de indicadores (o interfaz gráfica de usuario o editar el archivo de caché o lo que sea). Todo está documentado y mecanografiado, incluso los autores del proyecto pueden documentar y escribir su configuración expuesta. Debería leer CGold y los estándares modernos de CMake.

@Faless nadie niega que el lenguaje CMake es terrible. Pero la implementación es la mejor de su clase. He estado considerando la posibilidad de escribir un transpilador en un idioma mejor para aliviar el problema.

@ OvermindDL1 me encanta la sugerencia de leer CGold.

Si se pregunta eso, CMake se está utilizando incorrectamente.

Bueno, supongo que todos los programas que encontré estaban haciéndolo mal.

Para ser honesto, odio tener que cambiar las banderas a través de -DI_LOVE_CMAKE_AND_MAKE_DEFINES_LONG=on (¿en serio? on ?). Sin mencionar la idea de editar el archivo de caché O_o. O que, si quiero cambiar una bandera, básicamente termino teniendo que eliminar la carpeta de compilación y comenzar desde cero (¡porque, ya sabes, el caché es diferente!) ... tanto para las compilaciones incrementales ...

EDITAR: Además, una cosa que realmente me gustó de Scons (al menos en Godot, y esto podría ser posible con otro sistema de compilación, por supuesto), es que en realidad no leí ningún estándar o documento, solo ejecuté scons -h en la carpeta Godot

El 95% de los archivos de compilación que he visto en GitHub son incorrectos. La gente se vuelve perezosa a la hora de construir sistemas y sigue las prácticas del culto al cargo para improvisar algo.

@isaachier , solo como una métrica, ¿podría proporcionar 2 ejemplos de un archivo CMake malo y bueno? ¿Cómo consideraría esto: https://github.com/ARMmbed/mbedtls/blob/development/CMakeLists.txt ?

Mejor que la mayoría que he visto. Aún así, si no está usando CMake> = 3.0, entonces su experiencia con no es con CMake moderno.

Bueno, supongo que todos los programas que encontré estaban haciéndolo mal.

Tiendo a verlo bien hecho hoy en día.

Para ser honesto, odio tener que cambiar las banderas a través de -DI_LOVE_CMAKE_AND_MAKE_DEFINES_LONG = on (¿de verdad? ¿On?). Sin mencionar la idea de editar el archivo de caché O_o. O que, si quiero cambiar una bandera, básicamente termino teniendo que eliminar la carpeta de compilación y comenzar desde cero (¡porque, ya sabes, el caché es diferente!) ... tanto para las compilaciones incrementales ...

No tiene que usar on , puede usar true , 1 y una variedad de otras cosas. Es para que pueda elegir un nombre booleano apropiado que fluya bien con el nombre de la bandera.

Y nunca debería necesitar reconstruir la carpeta de compilación si cambia las opciones, cmake es excepcionalmente bueno para reconstruir cuando es necesario.

Sin embargo, todos los que toquen los sistemas de compilación C / C ++ deberían leer CGold , así como el manual oficial de CMake. Es muy fácil de usar CMake derecho, a menudo es mucho más corto también. No se deberían utilizar las antiguas metodologías CMake2. Sin embargo, en realidad, cualquiera que dependa de una versión de CMake 2.x está haciendo las cosas absolutamente mal (no usa los objetivos y las cadenas de herramientas correctamente, no configura las opciones correctamente, etc ... etc ...).

Gracias por las explicaciones, aunque sigo siendo escéptico, espero ver cómo funcionaría para Godot :).

@ slurps-mad-rips Su publicación con el supuesto código de ejemplo de CMake para habilitar el modo C ++ 11 es completamente CMake no estándar por una variedad de razones, que incluyen, entre otras:

• Configuración de variables no expuestas.
• Argumentos de la cadena de herramientas establecidos en un archivo que no es de cadena de herramientas.
• Absolutamente no cómo se hace algo como habilitar el modo C ++ 11.
• Ineficiente.

Dado el código de mesón autodescrito como simplificado que se muestra en esa publicación 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)

El equivalente simplificado (en el sentido de que también puede agregar más propiedades) CMake sería:

set_target_properties(godot PROPERTIES CXX_STANDARD 11)

Y eso asegurará que la cadena de herramientas utilizada sepa que necesita establecer ese modo (y puede especificar cómo manejar las fallas si usa un compilador que no lo admite también). Asumir marcas de línea de comando específicas del compilador en el archivo de compilación es una forma extremadamente pobre, ya que solo deberían existir en archivos de cadena de herramientas y el hecho de que el ejemplo de mesón que se muestra en la publicación anterior en realidad especifique argumentos específicos significa esencialmente que está codificando los compiladores compatibles.

Teniendo en cuenta que hay un archivo CMake Toolchain preconstruido para casi cualquier cadena de herramientas que se pueda imaginar (incluidos todos los estándares de MSVC de diversas variedades, GCC / Clang, android, iOS, emscripten, etc ... etc ...) usted No debería estar reinventando la rueda. Si el usuario que está compilando algo como godot quiere usar su propio compilador personalizado con argumentos de línea de comandos únicos (como tomar el compilador de Intel o tal vez algún chip dedicado o simplemente un simple RPi), entonces el script de compilación no debería tener que preocuparse por eso o necesita algún cambio (el código podría, por supuesto, pero de manera óptima tampoco debería hacerlo, ya que CMake puede decirle qué es compatible con las definiciones) y el usuario puede proporcionar su propio archivo de cadena de herramientas personalizado para que lo use la compilación.

EDITAR: Y nunca descarte el soporte generalizado. No puedo encontrar nada acerca de que meson pueda generar archivos de proyecto para KDevelop (el IDE que uso, que usa CMake como formato de compilación, ocasionalmente uso CLion en el trabajo, también usa CMake), donde casi todos los IDE salen ( ¡incluso Visual Studio!) puede abrir proyectos de CMake de forma nativa ahora (además de que CMake puede generar proyectos para la mayoría de los IDE directamente si así lo desea).

@ OvermindDL1

No es CMake no estándar en lo más mínimo. El ejemplo de código apunta a CMake 3.0, una versión en la que CXX_STANDARD no existe. Puede ver fácilmente desde aquí que usa target_compile_features con cxx_std_ y el número del estándar. Esta es la forma nueva y moderna de cmake para configurar la versión estándar. set_target_properties es un enfoque por objetivo más antiguo.
De hecho, el código exacto tomado de la documentación de

target_compile_features(mylib PUBLIC cxx_std_11)

Sin embargo, CXX_STANDARD no establece el soporte de libc ++ para clang ya que clang usa libstdc ++ de forma predeterminada en Linux a menos que esté configurado (y nunca está configurado para usar libc ++ de forma predeterminada en la mayoría de las distribuciones de Linux, ya que esto causaría errores de vinculador y problemas de ABI) . La única forma de hacerlo en este momento es comprobar si el compilador admite -stdlib=libc++ y pasarlo al compilador a través de una expresión generadora. No hay nada que involucre variables no expuestas con respecto a esto.

Además, no aprecio que dejes caer un comentario para hacer correcciones de un comentario que hice hace meses , especialmente dado que apuntaré a CMake sobre Meson en mi próximo intento. Le falta tacto y, en mi opinión, no aporta nada a la conversación.

CMake 3.0 es lo suficientemente antiguo como para dejar de ser compatible (10 de junio de 2014). Nadie debería ejecutar nada menos que CMake 3.10 actualmente, aunque se prefiere mantenerse actualizado con CMake 3.12 en este momento.

Y sí, el ejemplo que dio está totalmente desaconsejado (creo que incluso CGold menciona que no lo hace).

Y sí, me refiero a target_compile_features. ^. ^;

Sin embargo, CXX_STANDARD no establece el soporte de libc ++ para clang, ya que clang usa libstdc ++ de forma predeterminada en Linux a menos que esté configurado (y nunca está configurado para usar libc ++ de forma predeterminada en la mayoría de las distribuciones de Linux, ya que esto causaría errores de vinculador y problemas de ABI). La única forma de hacerlo en este momento es comprobar si el compilador admite -stdlib = libc ++ y pasarlo al compilador a través de una expresión generadora. No hay nada que involucre variables no expuestas con respecto a esto.

Todas las cadenas de herramientas actuales hacen eso para clang muy bien, al menos con C ++ 14, ya que es con lo que compilo (y un par de C ++ 17).

Además, no agradezco que dejes caer un comentario para hacer correcciones a un comentario que hice hace meses, especialmente dado que apuntaré a CMake sobre Meson en mi próximo intento. Le falta tacto y, en mi opinión, no aporta nada a la conversación.

Pido disculpas, no me di cuenta de la fecha ya que estaba leyendo el trabajo atrasado (y hay mucho trabajo atrasado aquí). Acabo de notar algo que parecía lamentablemente incorrecto para cualquier tipo de sugerencia moderna de lo que he visto durante algunos años y no vi ninguna corrección en las publicaciones poco después, por lo que quería que la información incorrecta no se propagara. :-)

La única forma de hacerlo en este momento es comprobar si el compilador admite -stdlib = libc ++ y pasarlo al compilador a través de una expresión generadora.

Sin embargo, sí, ese es el trabajo del archivo de la cadena de herramientas, que nunca debería aparecer en un archivo de compilación, nunca .

No hay nada que involucre variables no expuestas con respecto a esto.

Solo estaba haciendo referencia a las variables que se configuran y luego se usan en otros lugares en ubicaciones únicas, lo que se recomienda no en CGold, entre otros, por una variedad de razones.

CMake 3.0 es lo suficientemente antiguo como para dejar de ser compatible (10 de junio de 2014). Nadie debería ejecutar nada menos que CMake 3.10 actualmente, aunque se prefiere mantenerse actualizado con CMake 3.12 en este momento.

No deberían, y sin embargo, algunos lugares lo son. Para un motor de juego que intenta mantenerse actualizado y con la última tecnología, estar en la última versión de CMake está bien. Sin embargo, soy más que consciente de los proyectos extremadamente activos atascados en versiones anteriores como 3.5 y, en algunos casos, 3.4. De hecho, algunas bibliotecas C bien conocidas todavía apuntan a CMake 2.8 (ver: SDL2, libssh2, libgit2, etc.) Sin duda, es un gran dolor de cabeza.

Sin embargo, sí, ese es el trabajo del archivo de cadena de herramientas, que nunca debería aparecer en un archivo de compilación, nunca.

Hacer esta suposición (que los archivos de la cadena de herramientas están bien escritos y cubren todos los sistemas posibles y todas las versiones de CMake) está buscando problemas en el ecosistema general actual de C ++. Cuando se usa clang, la opción de compilar para libstdc ++ o libc ++ (especialmente cuando se usa a través de una llamada FetchContent ) debe ser proporcionada por la biblioteca. CheckIncludeCXX y CheckCXXCompileFlag siguen siendo necesarios incluso para algunos indicadores que no existen en GCC pero sí en Clang (y viceversa). El problema principal aquí es que las interfaces del compilador han divergido en gran medida y, en lugar de que los proveedores dediquen tiempo a facilitar las opciones de compatibilidad o incluso a discutir una interfaz común, ese comportamiento se nos impone a nosotros, el desarrollador, cuando todo lo que queremos hacer es escribir código. Créame, nadie en este planeta está más molesto por el estado de los sistemas de compilación y la gestión de dependencias C y C ++ que yo, pero se necesita pragmatismo para las bibliotecas existentes en CMake. Lo bueno de pasar de un sistema de compilación a CMake es que podemos comenzar con las últimas y mejores características. El problema se convierte en el estancamiento del sistema de compilación porque nadie quiere tocarlo (a excepción de esa alma valiente que pateó la generación de código compila los scripts en scripts separados), pero se necesitaría algo de trabajo para asegurarse de que no se salga de control. (lo cual será porque ... quiero decir que es un sistema de compilación. Siempre lo hacen)

Debo ser el único que disfruta escribiendo scripts de construcción, especialmente en CMake;).

Hacer esta suposición (que los archivos de la cadena de herramientas están bien escritos y cubren todos los sistemas posibles y todas las versiones de CMake) está buscando problemas en el ecosistema general actual de C ++. Cuando se usa clang, la opción de compilar para libstdc ++ o libc ++ (especialmente cuando se usa a través de una llamada FetchContent) debe ser proporcionada por la biblioteca.

Tales cosas deberían ser propiedades pasadas a la cadena de herramientas sobre las que la cadena de herramientas pueda actuar.

Además, si tiene una configuración única, es completamente razonable incluir archivos de cadena de herramientas, como por ejemplo para una compilación de Android muy personalizada o algo así (aunque el conjunto extendido de polly de cadenas de herramientas de cmake ha cubierto casi todo lo que he necesitado hasta ahora).

El problema se convierte en el estancamiento del sistema de compilación porque nadie quiere tocarlo (a excepción de esa alma valiente que pateó la generación de código compila los scripts en scripts separados), pero se necesitaría algo de trabajo para asegurarse de que no se salga de control. (lo cual será porque ... quiero decir que es un sistema de compilación. Siempre lo hacen)

En realidad, este es un gran punto para elegir CMake ahora, tiene un conjunto de estándares bien definidos a seguir que funcionan muy bien ahora después de lidiar con más de una década de experiencia previa, tanto buena como mala.

Debo ser el único que disfruta escribiendo scripts de construcción, especialmente en CMake;).

Lo disfruto en comparación con las alternativas con seguridad, aunque he escrito en él lo suficiente como para que tenga sentido para mí, aunque eso definitivamente no significa que lo sea para todos. ^. ^;

He usado muchos sistemas de construcción diferentes a lo largo de los años. El que tuvo más sentido para mí recientemente es CMake, pero definitivamente puedo ver el atractivo de SCons y lo flexible que es.

Incluso si SCons no es perfecto (¿qué sistema de compilación es?), Puede ser lo suficientemente bueno.

• ¿Proporciona las características necesarias?
• ¿Cuánta sobrecarga crea?

Si SCons obtiene un puntaje "suficientemente bueno" en ambos puntos, manténgalo.

¿Alguno de ustedes proponiendo el reemplazo de SCons por otra cosa realmente ha tomado el esfuerzo de aprender cómo funciona el sistema de construcción Godot?

Como sugerencia, es increíblemente complejo y no creo que haya muchos (o ninguno) proyectos que usen la construcción de CMake para esta cantidad de plataformas y que permitan tener varios objetivos de compilación configurados / compilados al mismo tiempo como lo hacemos nosotros.

Todos los esfuerzos de aquellos que dijeron "Transferiré el sistema de construcción de Godot a otra cosa" fracasaron estrepitosamente hasta ahora al darse cuenta de la complejidad de lo que SCons se está ocupando.

Para mí, es sin duda la mejor herramienta para el trabajo. Nada se le acerca. Si ustedes se quejan del tiempo de compilación base (que es solo 4/5 segundos en un sistema de gama media a alta con SSD), primero deberían intentar comprender todo lo que Godot hace al construir y ver cómo funcionaría en CMake o cualquier otra cosa. .

Eché un vistazo. No estoy convencido de que se pueda deshacer en CMake o en otros lugares. Pero también soy vago;). Veremos que pasa.

Como alguien que hizo el puerto de bazel. Pude llegar al punto en que el editor de Godot comenzó sin íconos.

Estoy bastante seguro de que CMake puede llegar a ese punto.

PD. El proyecto competidor más cercano con gran cantidad de plataformas es Urho3d.

Reproduje mi resultado de bazel en cmake.

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

Suponga que Visual Studio 2017 está 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() {
}

Instalar 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 juega con eso. El editor tiene los mismos problemas que la compilación de bazel (sin iconos), pero este ejemplo puede resultarle útil.

Nota

• Los iconos funcionan a partir de 71175b45f819e7cc5e4368dbf3e42abdd19af542
• Trabajo de Visual Script y GDscript

@fire Gracias por esto. Veo muchos lugares para mejorar que facilitarían el mantenimiento de estos archivos CMake (y el tiempo dedicado a agregar nuevas características o indicadores del compilador). Sin embargo, podría abordar este próximo fin de semana, el calendario está pendiente.

Impresionante trabajo @fire. Me alegra ver que alguien aquí puede producir algo en más de un sistema de compilación: smile :

Ligera actualización. Hoy tuve un tiempo de inactividad para abordar la construcción a partir del trabajo de soporte para cadenas de plantillas y esto podría hacer la vida un poco más fácil, en lugar de tener que procesar cadenas, agregarlas a una lista y luego procesar más cadenas y agregarlas a una lista, etc., etc.

Idealmente, los scripts de generación de código deberían poder ejecutarse como si fueran ejecutables sin conocimiento de la compilación. Siempre que se les pasen los archivos adecuados, estaríamos listos para realizar la migración completa a cualquier otro sistema de compilación.

@ slurps-mad-rips Sacar eso de su sistema SCons es una buena idea incluso en SCons. Puede colgar el GIL si tiene demasiada lógica en el proceso y perjudica el rendimiento de su construcción. Ocasionalmente, se producen algunas condiciones de carrera de cierre / apertura de archivo cuando se construye en paralelo (aunque a menudo se resuelve abriendo el archivo en un contexto).

Hola a todos,

Voy a usar este espacio para mantener a la gente actualizada sobre el puerto de CMake. Si me lo solicitan, haré un número por separado y haré un seguimiento de los cambios allí, aunque esta es un área agradable dado que tiene una gran cantidad de discusiones atrasadas y creo que sería un desperdicio perder tanto contexto.

Estoy divagando. Voy a tener que tomarme un descanso del puerto de CMake durante la próxima semana mientras asisto a una conferencia, sin embargo, pueden ver los esfuerzos de mi intento inicial de portabilidad aquí . Tenga en cuenta que voy a disparar para quedarme 1: 1 con la rama maestra actual, y como tal, forzaré los cambios a medida que lleguen para poder mantener un rebase. A medida que me acerco a la estabilidad, presentaré una solicitud de extracción para que sea más fácil trabajar con las rebases, así como para que sea más fácil comentar los cambios o hacer preguntas. Creo que este puerto a CMake no solo es factible, sino que al menos hará que una persona más (yo) esté bien versado en cómo Godot está realmente construido y construido y podría poner eso en palabras para que otros puedan entenderlo. una vista de pájaro del sistema de construcción. Este puerto también podría facilitar el flujo de trabajo de todos a largo plazo, especialmente con las versiones. No voy a mentir, tener el CONFIGURE_DEPENDS globbing de archivos mezclados con Ninja es bastante agradable.

Una última cosa, les sugiero que echen un vistazo a los módulos auxiliares de

¿Pudiste actualizar a la última versión alfa 3.1? El alfa podría ser un buen objetivo. Actualmente probando la compilación.

El título de este número es Considere mover el sistema de compilación a Meson . Creo que es inapropiado tener una discusión de CMake aquí. La discusión sobre CMake debería tener su propio problema. La comparación de Meson con cualquier otra cosa está bien.

@zaniar Ha habido mucha discusión en este hilo sobre los sistemas de compilación en general. El hecho de que el título no se haya actualizado no significa que vamos a crear de repente un nuevo problema y perder todo ese contexto para la discusión y comenzar de nuevo. Creo que pedirnos que de repente desperdiciemos varios meses de discusiones es inapropiado.

@fire He estado ocupado con el trabajo las últimas semanas, tengo una gran fecha límite para el viernes, y luego, después de eso, podría tener algo de tiempo para actualizar mi tenedor. Tengo algunos cambios a nivel local. Olvidé presionar hacia arriba, pero no tengo tiempo en este momento. (Entre este puerto del sistema de compilación, mi bifurcación de gnu m4, 15 propuestas que estoy escribiendo para la reunión de estándares C ++ de San Diego y CppCon en la última semana del mes, estoy absolutamente abrumado y no tengo a nadie a quien culpar, pero yo mismo)

Sí, Meson fue el objetivo de la discusión original, pero creo que es algo natural que se hayan mencionado y discutido otros sistemas de compilación desde entonces, y probablemente tenga sentido mantener la discusión dentro de este tema aquí en lugar de extenderla, como @slurps -dijo Mad-Rips.

Estoy de acuerdo con mudarme a CMake. Tiene mucho soporte con sus cadenas de herramientas. Las compilaciones de Android, por ejemplo, se vuelven muy fáciles en comparación con lo que Godot está haciendo en su archivo SCsub, que me parece "inmantenible".

Como proyecto de código abierto, Godot debería optar por soluciones que sean fáciles de mantener y que los contribuyentes tengan más probabilidades de conocer y a las que puedan contribuir.

Además, creo que esto es importante para la adopción de GDNative. Independientemente de la herramienta de compilación que se utilice, debe haber un ejemplo o proyecto estándar con un script de compilación fácilmente modificable que admita la compilación para todas las plataformas, incluidas iOS, Android, etc.

Además, los módulos normales deberían poder compilarse como bibliotecas compartidas. Esto está relacionado con # 19486 para que el motor se pueda separar en múltiples componentes descargables.

De hecho, estoy abordando estos. No he aumentado mis cambios en un tiempo porque he estado ocupado con CppCon, la próxima reunión de estándares de C ++, y vamos a hacer un lanzamiento la semana que viene en el trabajo. Basta decir que no he tenido mucho tiempo para terminar el puerto, pero la mayor parte de mi tiempo lo voy a dedicar a copiar los scripts de Python que generan el código C ++ en el futuro. Espero reanudar el trabajo en mi puerto este fin de semana. Actualmente estoy evaluando si adquirir automáticamente dependencias de terceros y aplicar parches almacenados en el repositorio o no. Una pregunta que tengo para los desarrolladores del núcleo es lo abierta que estarían a romper todos los repositorios de THIRD_PARTY el repositorio principal y en sus propios repositorios en la organización. Confío bastante en FetchContent en mis propios proyectos, y actualmente deseo poder hacer eso para estas dependencias de terceros que se han bifurcado ligeramente. Esto también me permitiría trabajar en cada uno de ellos para limpiar sus archivos cmake y al mismo tiempo realizar cambios incrementales en el repositorio principal una vez que se transfiera cada biblioteca de terceros.

Además, debo tener en cuenta que también estoy tratando de modularizar el motor en sí, por lo que estos componentes podrían actualizarse técnicamente por separado si alguien lo quisiera. Esto podría eliminar el problema que mencionó @chanon .

Por último, estoy agregando soporte para algunas herramientas de compilación adicionales para los desarrolladores principales si se encuentran en el sistema. Cosas como clang-format, clang-tidy, ccache o sccache, distcc, clang-check, address sanitizer, ubsanitizer, thread sanitizer, etc. Estos son en su mayoría linters (y pueden hacer que la cabeza de algunas personas explote con las advertencias y varios errores que ' que hemos estado detectando) pero será opcional habilitarlos. Como mínimo, el uso de sccache o ccache proporcionará alguna mejora de compilación al cambiar entre compilaciones y viceversa. Esperar a que se lance CMake 3.13 sería bueno, ya que esto resolvería parte del trabajo torpe en el que he tenido que confiar, pero lo importante es que lo estoy configurando para que el flujo de trabajo actual "para comenzar" sea para seguir ejecutando pip install través de Python 3.5 o posterior, sin embargo, estará dentro de un virtualenv para que la gente no tenga que meterse con el entorno de su sistema. (Esto también permitiría a otros experimentar con el uso de bibliotecas de Python adicionales como dependencias para varios scripts de generación de código y no tener que recordar desinstalarlos más tarde)

De todos modos, perdón por la actualización repentina del volcado de información a todos ustedes. Me dedico a terminar este puerto, pero la vida se interpuso recientemente 😅

Confío bastante en FetchContent en mis propios proyectos, y actualmente deseo poder hacer eso para estas dependencias de terceros que se han bifurcado ligeramente.

También puede usar Hunter y crear un repositorio de código específico de godot (un repositorio de git especial, como en github, por ejemplo) y acceder a todas las dependencias de esa manera mientras maneja la construcción, el almacenamiento en caché, etc., según sea necesario y correctamente. (o envíe todas las dependencias al repositorio "principal" del paquete Hunter y utilícelo directamente). Hunter es solo un archivo cmake (HunterGate.cmake) y una llamada para adquirir la información del repositorio de paquetes (ya sea oficial o personalizado).

Una solicitud humilde: el hilo de comentarios de este problema se ha vuelto enorme: ¿alguien que lo haya estado siguiendo podría resumir la discusión general hasta ahora en un comentario (y tal vez podría estar vinculado desde la publicación inicial de

Hola, todos. Planeo usar Godot como mi próximo motor para hacer un juego pequeño.

Vi esta conversación y como una persona que tiene experiencia tanto en CMake como en Meson (y autotools, tup, plain make, waf, SCons, probando proyectos completos en todas estas herramientas ...) quería dar mi opinión.

Los sistemas que utilicé más intensamente han sido Autotools, CMake y Meson. He estado usando Meson y CMake durante los últimos años, ya que descarté todos los demás sistemas de compilación en las configuraciones de producción.

Ventajas de cmake

• Generadores de proyectos maduros si te preocupas por Visual Studio (creo que Meson lo soporta bien hoy en día, pero no lo probé últimamente) y especialmente XCode (bastante seguro que falta más aquí).
• Adopción más amplia, más soporte en IDE
• Adopción más amplia -> más fácil de obtener contribuciones (aunque debo decir que Meson es muy fácil de aprender)

Ventajas de Meson

• muchos objetivos útiles por defecto: desinfectantes, unidades compiladas gratis, encabezados precompilados gratis, cobertura gratis ...
• la documentación patea el culo de la documentación de CMake: http://mesonbuild.com/
• Descubrí que la compilación cruzada es mucho más fácil
• Meson tiene una forma obvia de hacer cada cosa

Cual elegiria? Elegiría Meson si la compilación cruzada va a ser intensiva y te preocupan los tiempos de compilación rápidos (las compilaciones unitarias y los encabezados precompilados son compatibles de forma predeterminada).
Consideraría CMake ya que es el estándar y las contribuciones tal vez sean importantes para el equipo. Me elegiría personalmente a Meson, pero eso es solo una opinión personal, ya que la herramienta me parece mejor y eso me ahorra tiempo (scripts de CMake, manejo de espacios, expresiones generadoras, etc ... te estoy mirando).

Perdón por esta autopromoción descarada a continuación, pero creo que el contexto lo está pidiendo.

Tengo una pequeña serie de artículos sobre Meson más o menos básico aquí si alguien tiene curiosidad (4 artículos):

• 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

Tengo una respuesta (un poco desactualizada) sobre los sistemas de compilación en StackOverflow:

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

Solo mis dos centavos :)

@germandiago Ese es un gran artículo: he estado siguiendo este tema por un tiempo y sería maravilloso si pudiera trabajar con godot + CLion, que lamentablemente es solo CMake.

Sí, la mayoría de los IDE modernos son solo de CMake y / o algún sistema de compilación personalizado, y / o 'llamadas sin procesar' que pierden muchas funciones. CMake realmente se ha convertido en estándar, lo merezca o no.

@dorkbox, si puedo obtener estos cambios en los que estoy trabajando, definitivamente podrá trabajar en un flujo de trabajo CLion (cmake + ninja).

@germandiago

De hecho, ahora soy amigo (más o menos 😛), con el autor de meson a partir de la CppCon 2018. Ambos terminamos en el mismo artículo para la próxima reunión sobre los módulos titulados "Recuerda el Fortran", y estaré presentando su artículo en dicha reunión (¡es la próxima semana, en realidad!), y también estábamos en el mismo panel de sistemas de compilación en CppCon.

Me encantaría usar Meson. Si lee más adelante en el hilo, había probado un puerto de mesón, pero las cosas estaban demasiado integradas con Scons en ese momento. Todavía estoy sacando los scripts de generación de código actuales para que sean scripts 'ejecutables' separados, de modo que si, en el futuro, un cambio a Meson no estaría fuera de discusión. Sin embargo, es un trabajo lento, y he empezado a escribir algunas plantillas jinja para ayudar con la generación de código para que los scons puedan eliminarse por completo. Dicho esto, aunque mi bifurcación pública está desactualizada, la que tengo en casa está un poco más adelante (y sincronizada con una bifurcación privada). Lamentablemente, el trabajo se ha interpuesto en el camino y, lamentablemente, San Diego va a estar 'robando' más de mi tiempo. Después de eso, sin embargo, debería ser libre de eliminar algunos de los experimentos locales que tengo en mi bifurcación privada y finalmente volver al tren godot cmake. Me comprometo a asegurarme de que se pueda ingresar una solicitud de extracción completa sin tener también una interrupción masiva en el proceso de flujo de trabajo actual.

(Aparte: gracias a todos por la paciencia que han tenido mientras trabajo en esto. Sé que ha pasado un tiempo desde que lo empecé, pero ahora represento a mi empleador en el organismo nacional de EE. UU. Para el comité de estándares de C ++, así que mi agenda ha estado un poco más completo últimamente, especialmente cuando llegamos a temas importantes como módulos, corrutinas y rangos)

Sí, la mayoría de los IDE modernos son solo de CMake y / o algún sistema de compilación personalizado, y / o 'llamadas sin procesar' que pierden muchas funciones. CMake realmente se ha convertido en estándar, lo merezca o no.

Una posible herramienta útil para usar meson con IDE:

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

Hace que el IDE piense que está usando CMake, pero en realidad está usando meson debajo del capó.

Algunos antecedentes: fui un gran defensor de CMake durante muchos (¿10?) Años, pero me enamoré del mesón aproximadamente el año pasado. Meson parece estar escrito con la intención de tener las funciones útiles de CMake mientras corrige / previene muchas de las molestias de CMake. Un obstáculo al que me enfrento actualmente para adoptar meson en un proyecto es el soporte IDE. Acabo de descubrir la herramienta anterior, así que tal vez eso ayude.

Todos y cada uno de los sistemas de compilación tienen sus principales defectos, más que eso, no hay razón para cambiar eso desde el punto de vista técnico, ya sea scons, autotools, cmake, meson o lo que sea que tu religión sea make vs ninja. Creo que sería genial cerrar todos los demás errores de cambio del sistema de compilación como duplicados de este.

<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

Demuestra que reduz está equivocado @ slurps-mad-rips :).

Gorila de 800 libras en la habitación que aún no se ha mencionado. Una de las afirmaciones de Godot a la fama es la compatibilidad multiplataforma. Debería seguirse que cualquier sistema de compilación al que sea posible migrar debe estar disponible y probado en todas las plataformas a las que se dirige Godot. Quien esté detrás de dicha migración debería inclinarse a probar la migración en todas las plataformas compatibles, o al menos ser parte de un equipo que lo está haciendo. De lo contrario, vería tal movimiento como contrario a la filosofía de Godot y, en general, simplemente como una mala idea.

@lazybullfrog Tengo acceso a unas 5 máquinas independientes para escritorio y varios dispositivos móviles. Parte de mi adaptación a cmake es asegurarme de que haya cadenas de herramientas de cmake disponibles para todas las plataformas actuales.

@ slurps-mad-rips ¿Es uno de esos Haiku? Si no, estaría dispuesto a ayudar con la prueba. Gracias.

Parte de mi adaptación a cmake es asegurarme de que haya cadenas de herramientas de cmake disponibles para todas las plataformas actuales.

No olvide también que si necesita cmake toolchains para una plataforma, entonces probablemente haya una precompilada en https://github.com/ruslo/polly y si no la hay, entonces debería hacer PR. :-)

@ slurps-mad-rips ¿Cómo te ha ido? Noté que actualizaste el código el 14 de enero. Intenté compilar en Windows pero no encontré pkgconfig.

@fire life decidió lanzar algunas bolas curvas en mi dirección y tuve que cuidarlas. Cosas personales, desafortunadamente. Me he estado concentrando en el trabajo y terminando la biblioteca IXM que estoy usando para reducir la cantidad de trabajo que se copiaría en godot. Afortunadamente, me tomaré unas vacaciones en una semana (me dirijo a Kona para la reunión de ISO del WG21 de este trimestre este fin de semana), así que tendré algo de tiempo libre para trabajar en esto y (¡con suerte!) una compilación funcional para macOS, Linux y Windows soon ™. Android e iOS, seguidos de FreeBSD y Haiku (lo siento, @lazybullfrog , aunque eres más que bienvenido a probar temprano / seguido) serán mi próxima prioridad después de eso.

La mayor parte del trabajo / bloqueador hasta ahora ha sido extraer los scripts de Python en herramientas "instalables" que están separadas de los Scons y se ejecutan como procesos. La captura real de dependencias, configuraciones, etc. ha sido más fácil en comparación.

@ slurps-mad-rips, la vida también me ha arrojado algunas bolas curvas. Quizás deberíamos formar un equipo de béisbol. 😂

Afortunadamente, una de esas bolas curvas desde la última vez que comenté fue un Xeon de 8 núcleos con 32 GB de RAM con Haiku y FreeBSD instalados. Quizás pronto tenga algo de tiempo para ayudar a probar ambos.

De hecho, estoy encantado de que estas dos plataformas estén recibiendo atención. Esperamos probar pronto.

Creo que es razonable tener varios sistemas de compilación. Quizás un sistema de compilación oficial que esté bien respaldado y los demás se proporcionen en función de que "tú lo averigües". Los usuarios querrán usar su propio sistema de compilación independientemente, así que ¿por qué no agrupar su trabajo en un solo lugar?

Estaría dispuesto a contribuir con un puerto de Bazel si las cosas van de esa manera.

Creo que es razonable tener varios sistemas de compilación. Quizás un sistema de compilación oficial que esté bien respaldado y los demás se proporcionen en función de que "tú lo averigües". Los usuarios querrán usar su propio sistema de compilación independientemente, así que ¿por qué no agrupar su trabajo en un solo lugar?

Como empaquetador de Linux, he visto cientos de proyectos con varios sistemas de compilación. He visto algunos que tenían varios sistemas de compilación disponibles. Nunca he visto uno en el que no fuera un completo desastre, especialmente cuando los sistemas de compilación alternativos fueron aportados por colaboradores nuevos "por favor agregue CMake es tan genial" que luego desaparecieron del proyecto, y los encargados de mantenimiento no se molestaron en actualizarlo.

No hay ningún valor en el apoyo de varios buildsystems, y no voy a combinar cualquier PR va en esa dirección. Soy uno de los principales mantenedores de sistemas de construcción, y definitivamente no quiero tener la carga de mantener otros alternativos siempre que necesitemos cambiar algo.

Actualmente tenemos un sistema de compilación que funciona para todos y está bien respaldado, y no hay intención de cambiar. Si alguien realmente quiere investigar otras opciones, no dude en hacerlo, y si el resultado final también funciona para todos, puede estar bien respaldado y proporciona un valor agregado sin grandes inconvenientes, lo consideraremos.

Si alguien _realmente_ quiere investigar otras opciones, no dude en hacerlo, y si el resultado final también funciona para todos, puede estar bien respaldado y proporciona un valor agregado sin grandes inconvenientes, lo consideraremos.

Eso es lo que he estado haciendo con mi puerto de CMake. Actualmente, un cambio de archivo único o sin operación en scons toma más de 10 segundos en mi máquina actual (que tiene 64 GB de RAM, procesador comparable, etc.) Con ninja + cmake todo el proceso de configuración + generación toma menos tiempo, y el ninja la compilación termina en menos de 0.2 segundos en una compilación sin operación (en Windows, donde iniciar un proceso es costoso). También puedo usar la herramienta sccache de mozilla si está instalada, y eso ha sido extremadamente útil para editar las partes de codegen / ejecutar una compilación regenerada desde cero para asegurarme de que nada dependa de mi entorno local.

la mayor parte de mi tiempo lo he dedicado a extraer los scripts de generación de código en scripts de Python que podrían ejecutarse por sí mismos. Si eso fuera lo único que se fusionó con Godot, el tiempo que pasé en esto no habría sido una pérdida total. También resuelve el truco run_in_subprocess que existe actualmente para resolver problemas en Windows con paralelización.

Acabo de regresar de mi viaje y pude trabajar un poco. En este momento todavía necesito copiar algunos archivos de una ejecución manual de scons, pero he ido eliminando las fuentes generadas a medida que pasa el tiempo. Los encabezados license.gen.h y method_bind.inc son actualmente mi mayor objetivo, pero me estoy tomando unos días para lidiar con el jetlag + trabajo antes de abordarlos.

(también voy a cc @fire ya que ha estado interesado en este progreso por un tiempo)

Desde mi experiencia, Meson está totalmente jodido cuando construyo Android en Windows, simplemente no puedo hacer que funcione para compilar una de las bibliotecas de terceros que lo usa (libepoxy). Y creo que está demasiado ligado a cosas concretas del compilador.

Todo lo que deseo es un sistema de compilación que pueda generar archivos de proyecto y archivos de base de datos por separado del comando de compilación.

Cada vez que reviso una nueva rama con cambios importantes en los archivos, tengo que ejecutar Scons desde la línea de comandos para regenerar mis archivos vsproj, lo que también hace que se produzca una compilación completa de todos modos. En Scons por lo que he visto, no hay ninguna etapa de generación de proyectos de ningún tipo. Esta es también la razón por la que no admite la generación de bases de datos de compilación listas para usar para su uso en herramientas clang.

Actualmente, la única solución viable para codificar Godot en Windows (en cuanto a IDE) es Visual Studio; de lo contrario, prepárate para usar un editor de texto.

Scons es maravilloso y todo eso, pero cuando tengo un threadripper de 12 núcleos y 128 GB de RAM y tengo que esperar más de 12 segundos en Windows para compilar un cambio de línea única (la mayor parte es el pensamiento de Scons), se vuelve un poco molesto.

Pero la verdadera desventaja de Scons (y esto podría ser mi pereza en la búsqueda) es que no puedo compilar archivos cpp individuales. Ser capaz de compilar archivos cpp individuales sin construir todo el proyecto es un gran refuerzo de productividad y un verificador de cordura.

No son solo los cambios de línea los que llevan tiempo, incluso averiguar si hay algo que construir lleva tiempo ...

Ejecutando desde 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

Si desea crear solo un archivo de destino, especifíquelo en la línea de comando

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

Solo quería agregar que la última versión de CMake está agregando algunas de las características faltantes que las personas mencionaron anteriormente como razones para no usarlo.
Compilaciones de Unity: https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html
Encabezados precompilados: https://cmake.org/cmake/help/latest/command/target_precompile_headers.html

@Nosliwnayr Ambos han sido respaldados por complementos durante muchos años, están bien probados y ahora se querían lo suficiente como para ser incluidos. Esas nunca fueron razones para no usar CMake, ya que ha podido hacer ambas cosas en CMake durante mucho tiempo.

@bdbaddog
No lo entiendo, ¿tengo que especificar cada archivo manualmente? ¿Qué hace esa cosa .obj?
¿Cómo lo aplico a todo el proyecto? ¿Recompila automáticamente archivos individuales?

Espero que los tiempos de compilación se puedan optimizar aún más, poder compilar código C ++ casi instantáneamente sin trucos sería un regalo de Dios; después de ver lo rápido que compila godot, estoy realmente luchando por volver al motor irreal 4 (compilarlo , me tomó 45 minutos, pero ahora el motor de alguna manera se hinchó más, y tarda hasta 60 minutos, lo cual es una locura)

Quiero decir, creo que Godot tiene el potencial de compilar aún más rápido, y yo mismo reemplazaría el sistema de compilación, pero no tengo experiencia, así que literalmente no tendría idea de qué hacer.

@Nosliwnayr
¿Podemos evitar los encabezados precompilados? Creo que son basura total, solo mantenlo simple

también hacen que compartir proyectos sea mucho más molesto, y es simplemente una hinchazón interminable, con demasiados inconvenientes en mi mente, pero bueno, si alguien los usa de manera efectiva, soy genial, pero para mí parecen un truco sucio, en cambio de una verdadera optimización, y no me gustan los trucos baratos para ser honesto

después de usar el motor irreal 4, estoy cansado de 20 GB de mierda precompilada, simplemente no creo que valgan la pena, tiene que haber un sistema menos estúpido (el motor irreal 4, tomó hasta 60 ... 80 GB para mí, no es genial)

Si Godot se dirige en esa dirección, asumiré que los desarrolladores han perdido la maldita mente.

diablos, a la mierda, prefiero que se queden con los scons, si evita la bola de locura del motor irreal 4, creo que el enfoque más inteligente sería mejorar los scons, en lugar de reemplazarlos por completo, con un culo roto completamente nuevo sistema de compilación, cuando el actual funciona ... más o menos

Creo que el esfuerzo mental requerido para introducir un nuevo sistema es mucho mayor que simplemente mejorar lo que ya tenemos, y el nuevo compilador podría terminar funcionalmente roto durante meses.

Sin embargo, estoy seguro de que no me voy a quejar si se hace, pero con un componente de motor tan crítico, tienes que hacer todo lo posible, no hay vuelta atrás una vez que esto cambie

@ RaTcHeT302 : la línea de comando especificada es si desea compilar explícitamente solo un objetivo único (en este caso, un archivo de objeto) (y, por supuesto, los archivos de los que depende)

De hecho, si todas las personas que se quejan de problemas con SCons contribuirían a solucionarlos en lugar de sugerir cambiar un sistema de compilación complicado a otro más nuevo y brillante ... bueno, muchas de estas preocupaciones se solucionarían ...

@bdbaddog Scons no genera archivos de compilación de etapa intermedia. Realiza el paso de "dependencia del proyecto" en el mismo paso que compila, y no se pueden separar.

Es como decirle a CMake que genere los archivos del proyecto cada vez que acceda a su herramienta de compilación, ya sea MSVC, ninja-build, make, llvm, pick your poison.

Si cambio las ramas de git, no puedo actualizar Visual Studio sin realizar una compilación de línea de comando scons para regenerar los archivos .vsproj y .sln adecuados, y casi siempre limpio los cambios de la rama de compilación, ya que me he encontrado con problemas en el pasado.

Esos archivos intermedios no son solo para la construcción, también pueden ser utilizados por analizadores estáticos y otros proyectos.

Si bien estoy de acuerdo en que cmake no es perfecto (no me gusta tanto), y preferiría la flexibilidad de python, cmake tiene la mejor integración y soporte de todas las herramientas de compilación en la mesa.

Al convertir mi bifurcación a CMake, la mayor parte de la complejidad estaba en los archivos de generación de código. La idea de que la construcción es complicada es una falacia. La construcción no necesita scons porque es compleja. Es complejo porque usa scons.

Dicho esto, la razón por la que detuve el trabajo es porque me reuní con los desarrolladores principales en GDC en 2019 (en la reunión de GitHub) y dijeron que no tenían ninguna intención de cambiar a algo más útil, citando que preferirían hacer la compilación completamente en Linux y, de hecho, por lo que he visto, están violando el EULA que Apple requiere la aceptación para instalar herramientas de compilación para la compilación cruzada.

La mentalidad de los responsables es en gran medida "los fines justifican los medios" y no parece preocuparse por tratar la compilación como software, sino que godot la trata como una serie de scripts que producen una compilación.

No contribuiré con los cambios que hice a la generación de código de godot (a pesar de que es más legible y más rápido), y me he rendido por completo con este motor y seguí adelante con mi vida. Soy mucho más feliz si soy honesto. El motor ya tiene una deuda tecnológica considerable y veo que será un problema en aproximadamente 3 años, especialmente porque el comité estándar de C ++ está trabajando en un informe técnico de herramientas (estoy involucrado en esto y he estado presionando para que se estandaricen cosas como archivos de opciones hasta cierto punto, pero es solo un informe técnico, por lo que algunas personas se apartarán de él).

También es una pena. Mi compilación de CMake pudo detectar un montón de errores de análisis estático que han dado lugar a toneladas de problemas y se pueden resolver fácilmente, pero estoy demasiado agotado por haber discutido con los desarrolladores sobre esto en GDC para presentar errores o incluso intentar solucionarlo. ellos. Mi energía y mi salud mental se gastan mejor en otra parte.

No hay un mundo en el que los scons puedan manejar el próximo diseño de módulos de C ++ 20, por mucho que haya gritado cómo romperá muchas herramientas. No puede manejar el seguimiento de dependencias para eso, y requeriría que tenga un paso previo al escaneo, lo que ralentizará aún más el seguimiento de dependencias.

Por último, voy a sugerirle a la gente que no intente mejorar una herramienta que solo puede aceptar cambios menores. Los Scons necesitarían una reescritura completa desde cero y una gran cantidad de cambios importantes para obtener las mejoras que la gente busca aquí.

Sugiero que este problema se cierre ya que la discusión sobre el cambio del sistema de compilación se respondió en GDC 2019, pero los clientes potenciales ni siquiera creen que valga la pena perder el tiempo para comentar sobre este tema, que creo que muestra cuánto les importa la ergonomía. de desarrollo.

Siento que si el sistema de compilación existente se convirtiera al 100% en un modo plug and play, no habría ninguna razón por parte de los desarrolladores para no cambiar.

Construir solo en Linux es inútil. Tener un motor de juego que no se ejecute en Windows disuadirá a los desarrolladores de juegos serios.

Me gustaría tener la impresión de que los desarrolladores del juego se preocupan lo suficiente como para cambiar el sistema de compilación para satisfacer a sus usuarios.

Una de las razones por las que dejé Unreal es que el motor está diseñado principalmente para la creación de juegos Blueprint / front-end. Crear herramientas en módulos c ++ es extremadamente doloroso y complejo en Unreal.

Hasta ahora, en Godot ha sido decentemente agradable. Hacer que las compilaciones de C ++ sean más rápidas sería una gran ventaja para la comunidad.

IIRC utilizan Wine para ejecutar las herramientas de compilación de MSVC. Todavía no cambia tu punto, y estoy de acuerdo.

Construir solo en Linux es inútil. Tener un motor de juego que no se ejecute en Windows disuadirá a los desarrolladores de juegos serios.

Godot siempre se ha podido compilar en muchas plataformas, no solo en Linux ...

IIRC utilizan Wine para ejecutar las herramientas de compilación de MSVC. Todavía no cambia tu punto, y estoy de acuerdo.

Las compilaciones oficiales de Windows se compilan usando MinGW; no usamos WINE para ejecutar MSVC en Linux.

@marstaik : si cambia de compilación y ejecuta scons solo para generar los archivos del proyecto MSVS, debería poder especificar esos archivos como destino y no tener que hacer una compilación completa.

así que intenta:

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

SCons debería poder hacer esto sin hacer una compilación completa y también debería hacerlo correctamente sin necesidad de hacer una limpieza primero.
(Por cierto. Soy el encargado del proyecto SCons)

@bdbaddog Tuve que agregar vsproj = True a ese comando, pero parece haber funcionado

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

Editar: por alguna razón, debe agregar el indicador -j también ...

@bdbaddog Tuve que agregar vsproj = True a ese comando, pero parece haber funcionado

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

Editar: por alguna razón, debe agregar el indicador -j también ...

Muchos de estos indicadores no son SCons vanilla, sino que forman parte de la forma en que varios paquetes (Godot en este caso) implementan su sistema de compilación con SCons.
¡Me alegro de que hayas encontrado una manera!

¿Por qué utilizar SConstruct e insistir en no cambiar a otro sistema de compilación?

@tjysdsg La discusión anterior lo resume muy bien:

Cerraré esto porque hemos dejado claro a lo largo de los años que no tenemos ninguna intención a priori de cambiar el sistema de compilación. Estamos contentos con SCons y cualquiera de sus deficiencias puede y debe evaluarse individualmente, tanto dentro de nuestro propio uso de SCons como en sentido ascendente si se debe a las herramientas en sí.

El cambio a un sistema de compilación "más fresco" por el simple hecho de hacerlo no sucederá. La gran mayoría de los colaboradores principales está contenta con SCons y es el que ahora conocemos mejor. Cambiar a un nuevo sistema de compilación tiene tanto un costo de implementación como de aprendizaje, y hasta ahora no se ha demostrado que valga la pena.

Con todo, un cambio en el sistema de compilación no es algo que aceptemos de nuevos contribuyentes. Tiene que venir desde adentro, y todos los contribuyentes principales deben verlo como un cambio positivo para que tenga algún sentido. No cambiaremos el sistema de compilación solo para complacer a los nuevos usuarios que intentan construir Godot desde la fuente y de alguna manera no les gusta que tengan que escribir scons lugar de cmake o meson lo que están acostumbrados. Tampoco aceptaremos intentos de introducir un nuevo sistema de compilación opcional; por experiencia, sé que esto solo puede provocar inconsistencias, errores y diferencias de salida.

Por supuesto, estamos abiertos a cambiar de opinión si se pueden enumerar las ganancias claras (y mostrarlas con una prueba de concepto funcional) que superen los costos de cambiar el sistema de compilación, pero a partir de hoy y después de dos años de discusión aquí, personalmente no No veo el incentivo.

@ slurps-mad-rips lo dijo bien.

Es complejo porque usa scons.

y

Mi compilación de CMake pudo detectar un montón de errores de análisis estático que han dado lugar a toneladas de problemas y se pueden resolver fácilmente

Es totalmente desagradable que a CMake no se le dé una consideración seria, puedo pensar en muchas razones para deshacerse de SCons, pero ESPECÍFICAMENTE que CMake encuentre errores que Scons no encuentre hace que "valga la pena" usar otra cosa.

Cambiar a un sistema de compilación "más fresco" por el simple hecho de hacerlo no sucederá

CMake no es "más genial", es el estándar. Si realmente lo usara, entendería inmediatamente por qué.

Por supuesto, estamos abiertos a cambiar de opinión si se pueden enumerar las ganancias claras (y mostrarlas con una prueba de concepto funcional) que superen los costos de cambiar el sistema de compilación.

No estoy convencido de que alguien esté dispuesto a cambiar de opinión. Una vez más, @ slurps-mad-rips mostró claras ganancias, e incluso hizo todo el trabajo ... Ya está hecho.

Es vergonzoso, que representa la postura oficial del equipo de Godot, ignorar por completo sus esfuerzos para mejorar el proceso de desarrollo.

Entiendo muy bien tu dolor, pero sigo estando de acuerdo con los demás: toda la estructura
los sistemas tienen su
pros y contras y en general lo mismo. Rara vez hay una razón técnica
para cambiarlo.
En cuanto a razones políticas, no te servirán de nada a largo plazo.
correr. Todos
prefiere algo diferente. De todos modos nadie impide que nadie haga bifurcaciones
para lo que sea
razones, así que supongo que este es tan bueno como cualquier otro.

El viernes 21 de febrero de 2020 a las 13:38, dorkbox [email protected] escribió:

@ slurps-mad-rips https://github.com/slurps-mad-rips lo dijo bien.

Es complejo porque usa scons.

y

Mi compilación de CMake pudo detectar un montón de errores de análisis estático que
han dado lugar a toneladas de problemas y se pueden resolver fácilmente

Es absolutamente repugnante que no se le dé a CMake una seria consideración, puedo
pensar en muchas razones para deshacerse de SCons, pero ESPECÍFICAMENTE que CMake encuentra
errores que Scons no encuentra hace que "valga la pena" usar otra cosa.

Cambiar a un sistema de compilación "más fresco" por el simple hecho de hacerlo no sucederá

CMake no es "más genial", es el estándar. Si realmente lo usaras, lo harías
entender de inmediato por qué.

Por supuesto, estamos abiertos a cambiar de opinión si se pueden enumerar los beneficios claros.
(y se muestra con una prueba de concepto funcional) que superan los costos de
cambiando el sistema de compilación

No estoy convencido de que alguien esté dispuesto a cambiar de opinión. De nuevo,
@ slurps-mad-rips https://github.com/slurps-mad-rips mostró claras ganancias,
e incluso hizo todo el trabajo ... Ya está hecho.

Es vergonzoso, representando la postura oficial del equipo Godot, que
ignorar por completo sus esfuerzos por mejorar el proceso de desarrollo.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/godotengine/godot/issues/16014?email_source=notifications&email_token=AAABPU2PBIEK6PFKQ2LDTHLRD6VKVA5CNFSM4ENJ6NN2YY3PNVWWK3TUL52HS4DFVDVREXWG43V ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAABPU746R4YFHAI73Z57RTRD6VKVANCNFSM4ENJ6NNQ
.

@dorkbox - ¿cmake encontró errores de análisis estático? ¿O fue la salida de la base de datos de compilación de cmake ejecutada a través de las herramientas de análisis estático de llvm que los encontró?

@bdbaddog , @ slurps-mad-rips hizo el trabajo en esto, y sería mejor preguntarle. (Creo que sería el resultado del análisis estático de llvm, pero no soy yo quien hizo el trabajo para construir a través de cmake)

@slapin

Rara vez hay una razón técnica para cambiarlo.

¿Qué hay de las herramientas de análisis estático y el soporte de funciones de lenguaje moderno?

@bdbaddog @dorkbox Simplemente encendí clang-tidy para buscar cosas como "devolver referencias a locales no estáticos" y "desbordamientos de búfer" a través de CMake. También realicé un chequeo clang en algunas cosas y obtuve algunos resultados más. También pude hacer que include-what-you-use ejecutara, y encontré bastantes inclusiones de encabezado innecesarias.

Dicho esto, en realidad no "terminé" el puerto de cmake. La parte que nunca se transfirió fue todo el trabajo que hice al intentar cambiar los scripts de Python actuales que simplemente llaman f.write en algún archivo para generar un archivo desde JSON. Pude eliminar mucha de esa lógica y reemplazarla con un generador de plantillas genérico basado en jinja2. Esto también resolvió un truco que la compilación actual de scons hace en Windows donde lanza un script como ejecutable.

Sin embargo, esperaba mantener la paridad con la compilación de scons y, al menos, fusionar mis cambios en la generación de código. Esto no sucedió porque los scripts de Python utilizados para generar archivos fuente cambian constantemente y mantienen esos cambios sincronizados con mi plantilla jinja2 fue un ejercicio de frustración.

Dado el rotundo y enfático "no" que obtuve de los desarrolladores principales en la reunión de GDC GitHub, decidí que ya no quería contribuir a godot. Mis cambios no fueron deseados, no son deseados y son apáticos ante la opinión de cualquier otra persona sobre este asunto. No contribuiré a godot, ni a ninguna bifurcación de godot. Les deseo toda la suerte en tratar de convencer a los desarrolladores principales en el asunto, pero es como hablar con una pared de ladrillos. Inquebrantable, inamovible y apático ante la difícil situación de todos en este hilo.

Entonces, si SCons puede escupir la base de datos de compilación que se ingresa a las herramientas llvm, esto también podría hacerse desde SCons.

Entonces, si SCons puede escupir la base de datos de compilación que se ingresa a las herramientas llvm, esto también podría hacerse desde SCons.

Parece que existe la falacia del costo hundido con SCons. ¿Por qué no usar algo que sea más fácil, optimizado y que ya forme parte de las herramientas de compilación existentes, como cmake?

Desde el sitio web de scons:

En comparación con los scons, CMake es:

• Más rápido
• Requiere menos código para tareas comunes
  
  
  
  • Podría decirse que es más estable
  
  
  • Admite la salida a proyectos como Code :: Blocks, Xcode, etc.que scons no
  
  

@dorkbox : soy el codirector del proyecto SCons. Solo estoy atento a la funcionalidad deseada.

Los últimos lanzamientos y el próximo han tenido mejoras de rendimiento.

Además, tenemos relaciones públicas para la generación de archivos ninja y algunos miembros de la comunidad tienen herramientas de base de datos de compilación. Por lo tanto, es probable que algunos de los problemas se aborden (al menos parcialmente, si no completamente) en la próxima versión.

No tengo conocimiento de ningún problema de estabilidad que afecte al proyecto godot que no hayamos abordado. Si hay alguno pendiente, háganoslo saber.
(Comuníquese con nosotros a través de: https://scons.org/contact.html)

No estoy seguro de que cmake realmente requiera menos código para tareas comunes, estaría interesado en una comparación razonable.

Bueno, lo que más me alegra de los scons es la incapacidad de generar viejos
GNU hace makefile. Falta de ninja, puedo vivir con eso.
También manejo de la utilidad de compilación cruzada como cadenas de herramientas CMake y autotools
Las capacidades de compilación cruzada son un punto fuerte y débil.
El resto está bien ya que no soy una persona IDE. Mi IDE es un entorno UNIX.

El domingo 23 de febrero de 2020 a las 10:05 p.m. William Deegan [email protected]
escribió:

@dorkbox https://github.com/dorkbox - Soy el codirector del proyecto SCons.
Solo estoy atento a la funcionalidad deseada.

Los últimos lanzamientos y el próximo han tenido rendimiento.
Mejoras.

Además, tenemos relaciones públicas para la generación de archivos ninja y algo de comunidad.
los miembros tienen herramientas de base de datos de compilación. Por tanto, es probable que algunos de los problemas
que se abordará (al menos parcialmente, si no totalmente) en la próxima versión.

No tengo conocimiento de ningún problema de estabilidad que afecte al proyecto godot que
no he abordado. Si hay alguno pendiente, háganoslo saber.
(Comuníquese con nosotros a través de: https://scons.org/contact.html)

No estoy seguro de que cmake realmente requiera menos código para tareas comunes, estaría
interesado en una comparación razonable.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/godotengine/godot/issues/16014?email_source=notifications&email_token=AAABPU5TQQFET5RS2JDRY7TRELCHDA5CNFSM4ENJ6NN2YY3PNVWWK3TUL52HS4DFVREXP63JSMVBW5 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAABPU6UHPX3HJTWPAFTPATRELCHDANCNFSM4ENJ6NNQ
.