Godot: Envisagez de déplacer le système de construction vers Meson ou un autre système de construction

Pour ce que je comprends, l'outillage de buildsystem doit fournir:

• Compilation croisée (compilation sur toutes les plateformes cibles possibles à partir de la même plateforme hôte).
  
  
  
  • Par "possible", je veux dire que l'hébergeur le permet (donc macOS et iOS ne sont possibles que sur une machine Mac, et depuis Linux avec OSXCross).
  
  
• Un moyen de générer des fichiers (traduction de PO, classes de shader de GLSL, données de documentation de XML).
  
  
  
  • SCons sait que les fichiers générés sont des dépendances, leur modification déclenche donc une reconstruction des fichiers pertinents. Cela devrait aussi être pris en compte.
  
  
• Cibles multiples et options au sein des cibles (target=debug/release_debug/release, architecture en x86 ou ARM, 32 ou 64 bits).
• Options pour personnaliser la construction/activation des cibles supplémentaires (encapsuleur gdnative, pas de colle mono, activer/désactiver : modules, pilotes, fonctionnalités obsolètes, etc. un individuellement).

Je ne connais pas Meson, mais s'il fournit tout ce qui précède, cela devrait aller (si je n'ai pas oublié quelque chose). Bien sûr, quelqu'un doit subir la douleur atroce de réécrire le système de construction dans Meson, puis montrer que l'outillage et les temps de construction sont effectivement meilleurs pour Godot que pour SCons.

Notez que quelques dépendances tierces nécessitent la compilation d'un correctif avec Godot. J'ai remarqué que Wrap prend en charge les correctifs, mais il semble que le correctif doit être disponible quelque part pour être téléchargé, alors que je pense qu'il est plus facile à gérer s'il fait toujours partie du référentiel. De plus, certains d'entre eux nécessitent des indicateurs de compilation spéciaux qui ne doivent pas être appliqués à l'ensemble de la construction.

Je pense qu'une telle preuve de concept serait très utile car

• cela nous donne une meilleure idée si le nouveau système de construction gère tout ce dont nous avons besoin et à quel point il le fait bien
• cela nous donne des données concrètes au lieu d'abstraites pour discuter

Pour le deuxième point, cela signifie que nous pouvons voir la différence de vitesse de construction pour Godot , nous pouvons voir à quel point nos scripts de construction deviennent plus faciles (ou plus complexes), et nous pouvons comparer les différences plus facilement pour faire un choix au lieu de faire des études suppositions basées sur ce que l'on pense qu'il pourrait offrir.

--

Maintenant, personnellement, je dois dire que je ne suis ni pour ni contre cela, mais je pense qu'il y a plus de fruits à portée de main au lieu de (ou avant ?) changer l'ensemble du système de construction. Surtout à ce moment critique, où autant de mains que possible sont nécessaires pour s'assurer que 3.0 et les premiers patchs sont dans la meilleure forme possible. Mais si nous voulons améliorer le système de construction, je regarderais les temps de construction de CI et les tracas de la situation de construction Mono. (Je pense que ce sont sur Akien « s TODO / liste des aggrievances?)

De plus, les versions parallèles boguées sur Windows sont nulles, mais c'est plus sur une base personnelle qui serait bien si elle était corrigée.

TL ; DR :

• Je suis d'accord que la documentation / les ressources de SCons manquent, les scripts de construction étant faciles Python contrebalance quelque peu cela, IMO
• En tant que nouveau contributeur, le système de construction de Godot était l'un des moins ennuyeux à configurer, très peu de temps pour une première compilation réussie
• Je préfère voir l'effort consacré à l'amélioration de 3.0/3.1 autant que possible et peut -
• De meilleurs temps de build CI et des builds Mono plus faciles pourraient être plus importants

Mes opinions. :)

Je crois absolument que sortir la 3.0 et se concentrer sur les versions suivantes (3.0.1, 3.1) devrait avoir la priorité sur cela, pour mémoire.
Je sais pourquoi les gens n'aiment pas travailler sur des systèmes de construction (puisque c'est vraiment uniquement pour le bénéfice d'autres développeurs / en particulier des utilisateurs finaux férus de technologie - ce qui n'est pas sans importance, cela vaut la peine de faciliter la vie des développeurs et des contributeurs , mais finalement le bonheur des utilisateurs finaux est le but) et il y a tout ce truc de "coût d'opportunité", c'est-à-dire. quand le temps passé (ou perdu/perdu, selon à qui vous demandez) à améliorer le système de construction pourrait être consacré à améliorer le projet lui-même. (À moins que vous ne soyez comme moi et que vous ne puissiez pas vraiment travailler du côté C++ des choses de toute façon.)

Et finalement, SCons "fonctionne" vraiment, ce qui sera probablement assez bon pour la plupart des développeurs. s'il recueille même suffisamment de soutien pour finir par être travaillé pour commencer.

Cela dit, je pourrais lancer le POC plus tard cette semaine dans mon fork, pour ceux qui sont prêts à suivre les progrès à ce sujet (et probablement m'aider, car je n'ai pas beaucoup d'expérience dans l'écriture de systèmes de construction), mais je n'ouvrirai probablement pas de demande d'extraction pour cela pendant un certain temps.

Je ne trouve pas vraiment que SCons soit lent, et sa flexibilité (dont nous profitons énormément) est probablement inégalée par rien d'autre. SCons est également très éprouvée, je trouve qu'il n'a jamais plisse une construction.

Honnêtement, à moins que quelqu'un se porte volontaire pour réécrire l'ensemble du système de construction (pas seulement une preuve de concept) et montre que c'est soit plus simple (beaucoup moins de code) soit beaucoup plus rapide , je n'envisagerais même rien d'autre, même pas un peu.

Maintenant, personnellement, je dois dire que je ne suis ni pour ni contre cela, mais je pense qu'il y a plus de fruits à portée de main au lieu de (ou avant ?) changer l'ensemble du système de construction.

Ce n'est pas vraiment préjudiciable à ce changement. Je veux dire, la plupart des contributeurs de Godot travaillent sur leur temps libre et travaillent sur ce qu'ils veulent. Pour le cas de @NullConstant , il semble que ce soit "faire ceci ou ne rien faire" (je ne dis pas que vous ne voulez pas réparer les choses, juste qu'il est plus difficile de travailler avec la base de code C++ et la chasse aux bogues sur quelque chose d'inconnu), donc faire cela est une bonne chose en général.

De plus, l'argument "il y a de meilleures choses à faire" est le moyen de ne rien faire à l'OMI. Bien sûr, rien ne sera fusionné jusqu'à ce que nous soyons convaincus que cela ne cassera pas les choses et ne sera pas fait près d'une sortie. Je suis d'accord qu'il y a des choses plus importantes, mais cela ne veut pas dire que cela ne peut pas être commencé.

Le fait est que quelqu'un qui travaille là-dessus devra probablement le faire seul. Bien sûr, les développeurs principaux peuvent répondre à des questions spécifiques, mais cela n'arrivera pas plus que cela. C'est pourquoi SCons n'a jamais été considéré comme un remplaçant : personne jusqu'à présent ne voulait se salir les mains. Comme je l'ai déjà dit à propos de Bullet : quelqu'un doit le faire fonctionner et prouver que c'est possible et mieux, sinon nous resterons avec le statu quo.

Je pense que SCons est lent cependant. Pas très lent, mais des choses comme l'état de progression et le cache le rendent plus lent pour les reconstructions (l'utilisation d'E/S de disque pour lire à partir du cache le rend lent), donc je les désactive lors de la reconstruction. Ça prend un peu de temps pour commencer à faire des trucs, après c'est assez rapide.

Je ne sais pas si Meson sera beaucoup plus rapide, mais si quelqu'un est prêt à essayer, je ne suis pas contre.

Oh bien sûr, si quelqu'un prend le temps de le faire et montre que c'est une amélioration suffisamment importante pour justifier un changement, je suis tout à fait d'accord :)

Comme je l'ai dit, je ne suis pas vraiment équipé pour faire face à la chasse aux bogues C++ ou à l'ajout de nouvelles fonctionnalités sur ce front, donc je suis d'accord pour le faire à la place.

Je suppose que cela me donne (et/ou à toute autre personne travaillant dessus à l'avenir) un objectif assez clair et double à atteindre :

• faire en sorte que Godot compile avec Meson sous n'importe quelle forme pour commencer
• rendre les choses aussi faciles que SCons l'est actuellement, voire plus (en améliorant les vitesses)

Et je suppose que la vitesse de SCons n'est pas terrible-terrible (la majeure partie du temps du processus de construction provient de la liaison et de la compilation réelles de toute façon, donc le ralentissement de la surcharge du système de construction est probablement quelque peu négligeable), mais il est certainement pourrait être amélioré, et offrir Meson comme alternative pourrait bien être cette amélioration. On verra.

Le plus gros problème est probablement le remplacement des scripts de construction python pour la génération automatique de code comme les shaders, il ne semble pas que meson ait une fonctionnalité comme celle-là.

et offrir Meson comme alternative pourrait bien être cette amélioration. On verra.

Ce ne doit pas être une alternative, soit on y passe si c'est nettement mieux, soit on ne l'offre même pas. Avoir à supporter deux systèmes de build est fou.

D'accord, c'est juste.

Je vais commencer à le pirater au cours des prochains jours/semaines, voir si cela va quelque part et si c'est un effort qui vaut vraiment la peine d'être poursuivi (même si je finis par être la seule personne à y travailler pendant tout ce temps).

Je ferai un rapport si j'obtiens quelque chose de présentable (comme une référence).

Bien que, pas meson, je ferai un test dans les semaines à venir pour voir ce qu'il faut pour construire godot sous bazel pour windows 64 bit sous msvc.

Bazel est un autre système dont l'avantage est une description de build plus courte et des builds plus rapides. De plus, il est maintenu par Google, donc il ne va nulle part.

Quoi qu'il en soit, je ne peux pas vérifier cela, mais il est très probable que 99% du temps de calcul consacré à la construction de Godot soit passé dans le compilateur. Ainsi, même si les frais généraux du logiciel de construction étaient nuls, cela entraînerait une diminution de 1% du temps de construction. Même une diminution de 5% ne vaudrait pas la peine, à moins qu'elle ne permette moins de code et plus de fiabilité (ou si je me trompe :) ).

Pour la vitesse de construction brute d'un clone propre, je doute qu'il y ait une différence significative. Mais cela peut être important si vous considérez les vitesses de reconstruction. SCons reconstruit toujours beaucoup de choses qui n'ont pas été modifiées lorsque je tire un nouveau commit (en particulier OpenSSL et Bullet, qui sont tous deux de grandes bibliothèques et prennent un certain temps à construire).

Comme je l'ai déjà dit, SCons est lent à démarrer (cela prend quelques secondes avant de vraiment commencer à compiler). Si vous construisez toute la source, c'est négligeable, mais si vous ne modifiez qu'une ligne et que vous compilez pour tester, cela peut considérablement améliorer le flux de travail (l'IMO est ce qui compte le plus dans le système de construction : aidez les personnes qui travaillent avec le code) . Donc 5s diminués dans une construction de 10 minutes n'est pas pertinent, mais 5s diminués dans une reconstruction de 10s est une amélioration majeure.

Mais je suis d'accord que tout changement à cet égard devrait être testé beaucoup pour prouver qu'il fonctionne. Comme @reduz l'a déclaré, SCons n'a jamais gâché une construction, et c'est quelque chose à considérer.

Bazel est un autre système dont l'avantage est une description de build plus courte et des builds plus rapides. De plus, il est maintenu par Google, donc il ne va nulle part.

Il existe même sur Wikipédia une catégorie croissante de « choses que Google a abandonnées ». :)

@mhilbrunner Non, il est toujours maintenu https://github.com/bazelbuild/bazel

Leur argument était que ce n'est pas parce que Google l'a fait que cela durera longtemps.

Puisque nous avons adopté C# pour le développement de jeux, nous pourrions aussi bien essayer quelque chose comme Cake . Je ne l'ai pas essayé moi-même, donc je suis intéressé par ce que vous en pensez. D'une part, au moins, les scripts s'exécuteraient plus rapidement qu'avec Python.

Puisque nous avons adopté C# pour le développement de jeux, nous pourrions aussi bien essayer quelque chose comme Cake .

Je ne sais pas si exiger une installation Mono pour compiler Godot est une bonne idée, étant donné que Godot est principalement un projet C++ et peut être compilé sans support C#.

Le niveau de performance offert par Meson ou CMake (avec le générateur Ninja) devrait être plus que suffisant pour les besoins de Godot.

@Calinou, vous avez probablement raison, même s'il semble que tout le monde a sauté dans le train C#, personnellement, je l'utilise pour les scripts de jeux avec Godot et les applications de productivité avec Xamarin.Forms, aussi si je veux vraiment réduire les performances, je peux essayer quelque chose comme un convertisseur IL2cpp ou passez directement en C++. Je pense également utiliser le mono/csharp REPL et ASP.net pour des choses pour lesquelles j'utiliserais normalement JavaScript, Python ou PHP, comme par exemple des trucs liés au développement Web ou des scripts shell. Le fait est que cela ne me dérangerait pas non plus d'avoir un système de build basé sur C#, puisque je l'utiliserais déjà pour à peu près tout. Au moins pour moi, ce serait la fin de "putain... un autre langage que j'ai besoin d'apprendre... pourquoi ne s'en tiennent-ils pas au C++ et -insérez un langage dynamique/géré décent ici-"

Éditer:

Pour clarifier, exiger que le Mono Framework soit installé pour construire Godot ne me semble pas si mal, car les moteurs de jeu dits AAA nécessitent beaucoup plus d'espace disque :

• Godot <50MB
• Godot avec support Mono (<50Mo) + Mono Framework (~350Mo) = ~400Mo
• Irréel ~20 Go
• Unité ~10 Go
• CryEngine ~8 Go

En outre, nous pourrions coder en dur la prise en charge de Mono dans l'éditeur par défaut et avoir une logique pour détecter s'il faut ou non prendre en charge les scripts C# au moment de l'exécution, et demander le framework Mono ou les modèles d'exportation appropriés.

J'adore CMake, et meson a l'air cool, mais je suis plutôt d'accord avec cet article : http://www.rojtberg.net/1481/do-not-use-meson.

Je suis très intéressé à faire le jeu de jambes pour déplacer Godot vers Meson. La seule chose qui m'empêche actuellement de contribuer à Godot (et de l'utiliser) est Scons. J'ai dû l'utiliser il y a des années, et je n'ai jamais eu une expérience de développement incrémentiel aussi douloureuse de toute ma vie.

L'article lié ci-dessus a beaucoup d'arguments d'homme de paille, faisant valoir que CMake existe déjà et que nous devrions simplement l'utiliser. Les fichiers de construction de Meson sont extrêmement faciles à lire et utilisent une syntaxe proche de celle de Python. La conversion peut être rapide. Ce que je poste dans ce fil, c'est que si le jeu de jambes était fait, une demande de tirage serait-elle même envisagée pour la fusion?

Ce que je poste dans ce fil, c'est que si le jeu de jambes était fait, une demande de tirage serait-elle même envisagée pour la fusion?

Il sera envisagé, mais il doit être prouvé qu'il est avantageux par rapport aux SCons.

Une fois que vous considérez CMake juste un autre système de build et non le standard de facto, vous vous retrouvez avec trop d'options. Pourquoi mésonner sur SCons ? Ou bazel/buck sont des outils décents aussi? Mais le plus gros argument que j'ai en faveur de CMake est l'outillage conçu pour prendre en charge cet écosystème. Bases de données de compilation Clang, prise en charge de l'empaquetage sur plusieurs systèmes d'exploitation, etc. Les seuls inconvénients valables que j'ai entendus sont une mauvaise syntaxe et une mauvaise documentation, mais ce n'est pas vraiment assez fort pour que je modifie ma position à ce sujet.

Pourquoi mésonner sur SCons ?

Meson génère des fichiers ninja, ce qui est beaucoup plus rapide pour le développement incrémentiel. De plus, sous Windows, vous n'avez pas besoin d'effectuer de manipulation visuelle du chemin du studio. Meson fonctionne hors de la boîte. L'utilisation de meson sur scons réduirait beaucoup les frais généraux liés aux fenêtres de ciblage, en particulier pour ceux qui souhaitent utiliser Visual Studio (dont, je devrais noter, meson peut générer des projets tout comme CMake)

Ou bazel/buck sont des outils décents aussi?

Étant donné que bazel et buck sont tous deux écrits en Java (un godot de dépendance n'a que si vous ciblez Android, et même dans ce cas, on pourrait techniquement utiliser uniquement le NDK), je dirais qu'ils sont tout à fait une dépendance principale pour tous utilisateurs. Python est déjà dans la liste des dépendances, et vous pouvez facilement installer meson (et ninja) via un pip install meson rapide

Bases de données de compilation Clang

Meson prend en charge cela par défaut, car il s'agit d'une fonctionnalité par défaut intégrée à ninja

prise en charge de l'empaquetage sur plusieurs systèmes d'exploitation

Meson a également un support pour cela, et s'appuie fortement sur pkg-config le cas échéant

Les seuls inconvénients valables que j'ai entendus sont une mauvaise syntaxe et une mauvaise documentation

Meson a une syntaxe très similaire à python, s'appuyant sur des variables, des objets et des fonctions intégrées. À mon avis, écrire

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

vs

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

est beaucoup plus facile, d'autant plus que cmake est parfois sensible à la casse, et d'autres fois non. Lorsque vous commencez à vous familiariser avec les expressions génératrices, cela peut devenir extrêmement délicat.

# 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)

Le méson équivalent ressemble à :

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)

Je pense que je devrais noter, en passant, que de tous les systèmes de construction C++ là-bas, Meson est le moins terrible . Les arguments contre son utilisation ont tendance à être une image d'une bande dessinée Web, une main agitant la main sur la façon dont CMake est le plus utilisé, vous devriez donc simplement vous en occuper, et "hé au moins CMake n'est pas un outil automatique".

Mais surtout (et je pense que c'est une chose vraiment importante, surtout pour ceux qui utilisent godot comme pour gdnative), Meson supporte nativement les en-têtes précompilés. CMake ne le fait pas (et utiliser cotire pour pirater le build peut causer plus de problèmes que cela n'en vaut la peine).

Je ne peux pas vous dire à quel point cela pourrait accélérer la construction pour les utilisateurs de gdnative, mais ce sera un coup de pouce significatif sur gcc et msvc (à tout le moins, une augmentation des performances sur msvc est inévitable). Ajoutez l'utilisation de extern template pour les très petites quantités de code modélisé trouvées dans godot, et vous pourriez voir des améliorations de temps de construction décentes, qui sont importantes pour les constructions itératives et incrémentielles.

Meson génère des fichiers ninja, ce qui est beaucoup plus rapide pour le développement incrémentiel.

Notez que CMake peut également générer des fichiers de construction Ninja au lieu des Makefiles traditionnels ; cela se fait en passant -G Ninja à sa ligne de commande. Cela fonctionne assez bien sur la plupart des projets que j'ai essayés et est légèrement plus rapide dans l'ensemble (de plus, il utilisera tous les threads du processeur par défaut).

Meson gagne toujours dans les comparaisons de performances brutes que j'ai vues, mais cela aide certainement à combler l'écart entre les performances de Meson et CMake.

Oui, cependant, CMake n'installe pas automatiquement ninja pour vous, et ce n'est pas le générateur par défaut. La plupart du temps de CMake est consacré à la configuration du projet, d'après mon expérience, et bien que les versions récentes de CMake aient considérablement amélioré les performances, tout le monde n'aura pas le dernier CMake.

OK c'est assez complet ! Je suis heureux que vous ayez une bonne idée des fonctionnalités que vous appréciez dans un système de construction. Je pense toujours qu'il devrait y avoir un système de construction standard dans le monde C++ sur lequel les projets peuvent s'appuyer. Je souhaite juste que meson soit un transpileur CMake par opposition à son propre truc.

Je pense toujours qu'il devrait y avoir un système de construction standard dans le monde C++ sur lequel les projets peuvent s'appuyer.

Croyez-moi, personne ne le veut plus que moi. Je suis devenu une sorte de gobelin poubelle du système de construction et j'ai même donné une conférence à leur sujet à la CppCon. Malheureusement (ou heureusement ?) Je me soucie beaucoup des systèmes de construction, presque jusqu'à l'obsession. :)

Je veux juste dire ceci, mais chaque fois que j'ai fait une longue version de Godot sur Windows, j'ai noté que Python prenait systématiquement > 15% de mon CPU. Je doute que ce ne soit que lent à démarrer.

Qui va fabriquer un petit prototype de moteur godot construit avec meson ? Je ne suis jamais arrivé au point de créer un petit test pour bazel.

Une version 2D uniquement de godot devrait être suffisante pour tester avec toutes les options désactivées.

Le premier obstacle auquel j'ai été confronté était core/make_binders.py. C'est le code généré automatiquement que godot utilise.

J'ai fait un premier prototype dans le système de build Bazel mais je discuterai de la configuration sur un autre problème. https://github.com/godotengine/godot/issues/18518

Vous n'avez pas le temps pendant la semaine, mais d'autres peuvent développer le Bazel BUILD.

Lol comment Bazel s'est impliqué?

Puisqu'il pourrait y avoir une opportunité unique de passer à un système de build différent, ne devrions-nous pas rechercher les meilleures options possibles ? Pour ma part, je serais intéressé à voir un tableau de comparaison Cake vs Bazel vs Scons, même si je dois admettre que je n'ai aucune expérience avec Cake pour faire le jeu de jambes pour ces tests.

@rraallvv tu veux dire Cake ou CMake ?

@isaachier Mon mal, je parlais de www.cakebuild.net , j'aurais dû être plus précis, désolé pour ça.

N'est-ce pas juste pour C# ?

@isaachier Je ne sais vraiment pas, pendant tout ce temps, je supposais que Cake en était capable, tout comme SCons étant écrit en Python et prenant en charge C++. Néanmoins, je viens de demander à leur chat gitter , je vais re-poster ici la réponse.

@rraallvv pour mémoire, je pense que l'idée d'une comparaison côte à côte des principaux systèmes de construction est une excellente idée. Voici ce que j'ai trouvé en ligne qui, je pense, est assez impartial (pas écrit par les développeurs du système de construction): 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.

Mon avis personnel :

• CMake : Langage assez laid, mais omniprésent et pratiquement le standard de l'industrie.
• SCons : statut lent, ancien et IDK. Utilise Python.
• meson : Nouveau système de construction cool basé sur Python qui n'est pas incroyablement lent. Le principal inconvénient est la trajectoire. On ne sait pas si ce sera juste une autre saveur du système de construction de la semaine.
• Autotools : Ancien, aucun support d'outillage (c'est-à-dire bases de données de compilation pour le support de l'autocomplétion Clang ou l'analyse statique). Pas de prise en charge de Windows. A éviter à tout prix.
• bazel : un gestionnaire de packages/système de construction Google en un seul. N'ajoute pas grand-chose à CMake avec un plugin tel que Hunter . De plus, les logiciels Google ont tendance à se concentrer sur ce dont Google a besoin, et non sur le grand public. Trop nouveau pour évaluer la trajectoire à long terme.

J'essaie de pousser CMake chaque fois que j'en ai l'occasion parce que je veux un standard de facto pour C++ et CMake a actuellement la plus grande "part de marché".

@isaachier Merci d'avoir partagé cette information, je pousse C# car il n'y a pas de système de build qui prend en charge les scripts en C++, cela peut sembler idiot mais je ne sais pas pourquoi quelqu'un ne l'a pas encore fait, par exemple ce C++ REPL pourrait être utilisé pour un système de construction si l'on veut passer au niveau supérieur et mettre fin au débat sur lequel est le meilleur, le plus rapide, etc.

Je ne comprends pas. C++ serait probablement un langage de construction horrible. La lenteur a plus à voir avec le noyau du système de construction interne AFAIK pas avec les détails du langage de script utilisé.

@isaachier Je suppose que SCons est si lent car il a été écrit en Python, mais si quelqu'un devait se charger de porter l'ensemble du système de construction en C++ et de le faire également compiler des scripts C++ JIT pour exécuter ces versions, ce serait beaucoup plus rapide. Peut-être que la même chose pourrait être vraie pour tous les systèmes de build.

C'est une bonne idée mais meson n'est pas considéré comme lent par la plupart des comptes, pourtant il est écrit en Python.

Je doute que meson soit une saveur de la semaine car le projet GNOME abandonne actuellement les outils automatiques au profit de meson.

De plus, Scons est lent non pas parce qu'il est écrit en python, mais parce qu'il exécute également le build. C'est un système de construction directe, comme make ou ninja, mais il utilise également des quantités massives de XML pour les définitions et une grande partie de son code n'est en fait que des conversions XSLT.

Meson, d'autre part, exécute ses scripts de construction pour générer un arbre de dépendances, puis le vide dans un fichier ninja. Meson est rapide, car le ninja est rapide. De plus, tout n'est pas une chaîne dans Meson, comme dans CMake.

Enfin, je dois noter qu'il existe plusieurs systèmes de construction de développement où vous pourrez scripter en C++ (j'écris en fait l'un d'entre eux). Cependant, demander à godot de passer à un système de construction qui n'existe pas encore ( et pire, que j'écris moi-même) est un peu arrogant, à mon avis pas si humble ;)

Je tiens également à réitérer que, dans le cadre du flux de travail de développement actuel, python est une nécessité. Il en va de même pour le méson. Et cela rend le passage à meson aussi simple qu'un appel à l'outil pip de python.

Je suis tout à fait d'accord @reduz que je ne trouve pas vraiment que les SCons soient lents non plus.

Comme l'a dit @slurps-mad-rips :

Scons est lent non pas parce qu'il est écrit en python, mais parce qu'il exécute également le build

homme scons:

scons prend en charge la construction de plusieurs cibles en parallèle via une option -j qui prend comme argument le nombre de tâches simultanées pouvant être générées :
scons -j 4

J'ai un processeur avec 8c16t, donc utiliser "scons p=x11 -j 18" est très rapide pour moi.
C'est 10 fois plus rapide que d'utiliser "scons p=x11" comme paramètre par défaut "-j 1".
Quelqu'un a-t-il un processeur monocœur en 2018 ?
Laissez votre CPU fonctionner pleinement.
s'il vous plaît essayez-le.

Tout le monde n'a pas ces gros processeurs, mais plus important encore, meson (enfin, ninja) est beaucoup plus rapide lors des recompilations incrémentielles. Scons, par défaut, effectue une somme de hachage MD5 pour voir si un fichier a changé. Godot utilise le paramètre d'horodatage MD5, ce qui signifie qu'il ne hachera un fichier que si un horodatage a changé. C'est toujours ridicule.

Je suppose que la meilleure façon de prouver ce qui est mieux est d'en écrire un nouveau et de voir :)

Scons n'est pas rapide pour beaucoup de gens, en particulier les utilisateurs de Windows qui rencontrent des problèmes avec tout ce qui est supérieur à -j 1.

@slurps-mad-rips cela dépend du projet. ninja semble exagérer un peu trop sa vitesse. Voir cet article : http://david.rothlis.net/ninja-benchmark/. Il semble que compter les fichiers sources soit votre meilleur pari ici. Si <20K ne fera pas beaucoup de différence.

@isaachier cette référence se situe entre make et ninja, pas ninja et scons, vous devrez donc me pardonner si je ne veux pas y prêter attention. ;)

Je suppose que la meilleure façon de prouver ce qui est mieux est d'écrire un nouveau sur et de voir :)

Je suis d'accord, il ne sert à rien de se débarrasser des vélos. Si vous avez une opinion sur un meilleur système de build, implémentez-le et prouvez qu'il est meilleur. Sinon, il s'agit d'une discussion d'opinion et ne mènera nulle part. @fire a déjà fait un test partiel avec bazel : https://github.com/godotengine/godot/issues/18518.

@slurps-mad-rips est un sujet totalement différent, pas SCons. Je voulais juste dire que make vs ninja n'est pas une différence folle.

Légère mise à jour : j'abandonne l'idée d'essayer de passer à meson. Cela a été au coup par coup et bien que les fichiers de construction soient légèrement plus faciles à lire, rester à jour avec le système actuel est l'endroit où la plupart de mon temps libre (maintenant rare et en nombre limité) est passé, au lieu de déplacer des scons vers meson.

À l'heure actuelle, beaucoup de code et d'opérations sont placés directement dans les scripts scons, ce qui rend le passage à un autre système de build plus difficile. Si quoi que ce soit, je dirais que du temps devrait être passé à découpler les scripts python existants qui génèrent du code à partir de scons, car cela faciliterait grandement le passage à un autre système de construction comme meson, cmake ou même bazel.

Heureusement qu'un correctif vient d'être fusionné pour déplacer toute la génération de code. https://github.com/godotengine/godot/pull/17595 N'abandonnez pas !

Co-Manager du projet SCons ici. Quelques remarques :
1 - SCons est en cours de développement et depuis notre migration vers Github, nous constatons une augmentation du taux de pull request.
2 - Nous avons identifié quelques parties spécifiques des SCons qui sont responsables d'environ 50% du temps de construction incrémentiel nul et nous travaillons activement à résoudre ce problème. (La fonctionnalité Subst)
3 - Nous avons commencé à prendre en charge Python 3.5+ (ainsi que 2.7.x) avec SCons 3.0
4 - Permettez-moi de suggérer qu'au lieu d'essayer de porter sur N différents systèmes de construction, contribuer un peu de temps pour aider à améliorer les SCons pourrait être une utilisation plus efficace du temps de développement
5 - Nous avons identifié et traité via le profilage de certains des fruits à portée de main dans l'amélioration des performances qui ont été publiés dans les versions 3.0.0 et 3.0.1. Si vous utilisez une version antérieure, la génération incrémentielle nulle peut être 5 à 15 % plus lente. (en supposant que Python 2.7.x)

Comme toujours, le projet SCons est prêt et disposé à aider les projets qui utilisent SCons avec les problèmes qu'ils rencontrent.

Quelques "statistiques" pour SCons & godot.

J'ai utilisé (et j'utilise toujours) un Q6600 qui est un processeur à 4 cœurs de 2008 environ avec 2,4 GHz (et un nombre d'instructions par cycle inférieur) que les processeurs que nous utilisons "tous" aujourd'hui (i7s).

Sur Q6600, une construction a pris entre 3 et 5 minutes (ou plus, mais le nombre exact n'est pas si important), dont environ 35 à 40 secondes ont été consacrées par SCons à analyser l'arbre des dépendances et autres (le travail de préparation) ... ainsi, 80% du temps passé à exécuter le processus cl.exe (compilateur MSVC) encore et encore.

Donc, en termes de performances et d'optimisation, à moins que SCons (en réalité python, pas SCons) n'ait un terrible système d'appel de processus qui prend plus de temps qu'il ne le devrait ou que certains autres outils ne compilent pas un fichier par processus (comme SCons le fait actuellement) et le 1 processus par fichier est important (je ne suis pas un expert des internes de compilation cl.exe et des frais généraux de démarrage), la seule optimisation des performances qu'un système de construction plus rapide produirait est probablement dans la phase de construction de l'arbre de dépendance et d'autres travaux préparatoires à la complication .

Donc, nous optimisons ces 35-40 secondes sur une construction de 5 minutes (sur les i7 maintenant, nous optimisons probablement une étape de configuration monocœur de 20 secondes sur une construction multicœur de 3 minutes).

Donc, pour récapituler, si je me souviens bien, 3 à 5 minutes sont en fait une version multicœur à 4 cœurs, alors qu'une version à un seul cœur prend environ 10 ? Je dois refaire mes tests...

Ainsi, "optimiser" les SCons signifie plus ou moins optimiser les 35 premières secondes du démarrage des builds...

C'est en ce qui concerne les "optimisations" en ce qui concerne SCons par rapport à un autre système de construction plus rapide... Il est possible que la compilation réelle puisse être optimisée un peu en évitant d'appeler un seul cl.exe pour chaque fichier obj, mais ce n'est que si la surcharge du processus est importante (je crains que le disque dur ne soit toujours le véritable goulot d'étranglement des E/S là-bas (et non le processeur), ce qui n'est pas évitable / atténuable sans SSD)

Tous ces paragraphes ci-dessus considèrent une "version complète". Cela dit, SCons "triche" si tout est déjà construit et réussit ses vérifications de cohérence lourdes. d'une construction incrémentielle). Cela nécessite cependant ces 35 à 40 secondes de précalcul complet de l'arbre de dépendance...

Ainsi, une "construction incrémentielle" dure environ 45 secondes sur mon ancien ordinateur, et je pensais quand j'étais un noob il y a 2 ans que ce serait lié au processeur, mais en réalité, il pourrait être lié aux E/S (vérification de plusieurs milliers de fichiers sur le disque dur ).

Mon idée bidon d'il y a 2 ans était d'essayer d'attacher un "observateur" de système de fichiers aux SCons, de faire exécuter les SCons et de recompiler un seul fichier modifié (et ses dépendances, c'est automatique), puis de lui faire tout relier à nouveau... bien que je me rende compte aujourd'hui que la liaison exécuterait probablement encore un balayage de dépendance complet... cela dit, le balayage/la reconstruction de l'arbre de dépendance peut être tué avec une option, puis SCons utilisera son arbre dep mis en cache... ce qui permet d'économiser environ 15 à 20 secondes de l'étape de pré-calcul de 35 secondes (les 15 premières secondes semblent inévitables) bien que cela ne garantisse pas toujours une construction "parfaite" comme le fait SCons (bien que cela puisse ne pas être important pour les constructions incrémentielles en développement... si vous décidez que la vitesse est un compromis valable).

J'ai maintenant suffisamment de connaissances pour pouvoir probablement le pirater via npm et npm watch... et ou un autre système que je ne connais pas actuellement... Mais c'est pour plus tard, et quand j'aurai le temps (pas actuellement).

Cela devient un peu long donc je vais le terminer ici, mais le but de ces paragraphes était de vous donner des informations "statistiques" plutôt que de décourager quiconque (allez-y si vous aimez travailler sur des systèmes de build), comme j'ai moi-même aimé réparer des trucs dans les SCons de Godot. J'espère que certaines informations vous ont été utiles ici.

Si vous souhaitez répliquer / refaire mes statistiques, parcourez simplement les documents SCons jusqu'à ce que vous activiez les informations statistiques (trucs de minuterie) et / ou trouviez un moyen de désactiver la redolution des dépendances (ces 20 à 30-35 premières secondes de "pré-calcul" )...

Ou pour une solution un peu moins manuelle, les informations de débogage du minuteur devraient déjà être présentes (modifier : ce n'est probablement pas le cas, quelqu'un a fait ce qui ressemble à une douce mise à jour de la génération du projet vs, ce paragraphe peut être une information obsolète) dans le projet VS automatisé généré par SCons (à la fin du fichier SConstruct)... vous pouvez trouver des informations sur la façon de générer un projet VS dans le "Tutoriel de compilation Windows" sur le site de godot. Vous pouvez ensuite exécuter SCons à partir de VS, je pense que le projet généré devrait toujours fonctionner, même si je ne l'ai pas testé dans Godot 3... ...

En espérant que quelqu'un ait trouvé cette information utile.

@Griefchief Juste pour clarifier un peu les choses, je pense que nous

En effet, la "construction incrémentielle nulle" (rien n'a en fait besoin d'être reconstruit, mais les scons devront toujours traiter l'ensemble de l'arbre de dépendances pour s'en assurer) est le cas sur lequel nous travaillons.

Certains profils ont mis en évidence des inefficacités dans le traitement des lignes de commande (qui doivent être effectuées pour chaque cible pour s'assurer qu'elles n'ont pas changé) ont été identifiées. La majeure partie de cela est la logique Subst(). C'est un code délicat et jusqu'à présent, il a été implémenté de manière plus simple et sûre, mais pas terriblement efficace.

Un autre point chaud du temps est la lecture et l'écriture des fichiers sconsign, actuellement implémentés avec cpickle et toujours lus et écrits dans leur ensemble. Nous avons quelques idées sur la façon d'accélérer et/ou de rendre plus incrémentiel. Quoi qu'il en soit, regardez les futures versions pour les améliorations.

En passant, vous pouvez essayer MSVC_BATCH pour voir si cela accélère vos builds Windows :

MSVC_LOT
Lorsqu'il est défini sur n'importe quelle valeur true, spécifie que SCons doit compiler par lots les fichiers objet lors de l'appel du compilateur Microsoft Visual C/C++. Toutes les compilations de fichiers sources du même répertoire source qui génèrent des fichiers cibles dans un même répertoire de sortie et qui ont été configurés dans SCons en utilisant le même environnement de construction seront construites en un seul appel au compilateur. Seuls les fichiers source qui ont changé depuis la construction de leurs fichiers objets seront transmis à chaque invocation du compilateur (via la variable de construction $CHANGED_SOURCES). Toutes les compilations où le nom de base du fichier objet (cible) (moins le .obj) ne correspond pas au nom de base du fichier source seront compilées séparément.

@bojidar-bg oui, oui, je parlais aussi des versions incrémentielles, merci pour le conseil :D

@bdbaddog Salut baddog, juste pour votre information, j'ai en fait écrit ce gros commentaire avant de voir votre commentaire, donc, il ne fait en fait référence à rien dans votre commentaire en particulier... mais vous avez réussi à mentionner certains des " préoccupations" J'ai eu (des informations pour d'autres personnes vraiment) pendant que nous écrivions tous les deux nos commentaires en même temps...

Et je ne voulais pas vous y envoyer un ping parce que je ne voulais pas "perdre" votre temps :D, mais je suppose que je le ferai si je passe plus de temps sur godot build/scons à l'avenir (je prévois de, je je suis juste très occupé))

Merci pour votre contribution ici!

@bdbaddog BD, puisque vous fournissez un support, si je peux demander ici :

Si j'attache npm watch au système de fichiers (source de godot) et que je sais quel fichier exact a été modifié, cela m'apporterait-il des avantages avec SCons ?

Maintenant, je peux exécuter scons via npm watch et y envoyer le fichier ...

scons [godot options] le/fichier/qui/a/a/a été modifié.

cela va évidemment recompiler ce fichier, évitant probablement tout l'arbre dep de Godot? correct? Alors maintenant, la traversée de l'arbre dep ne prendra pas 20 secondes, mais moins de 1 prob, mais j'obtiens 1 fichier .obj mis à jour (ou plus, selon ce que vous modifiez). Il ne passera pas en fait par l'ensemble de l'arbre de dep godot pour ce fichier ? J'ai un avantage en moins de traversée de l'arbre dep dans cet exemple (et peut-être d'autres avantages dans la phase de précalcul qui ne peuvent pas être obtenus en réutilisant le cache de l'arbre dep, comme moins de fichiers globalement à parcourir ?) ?

Maintenant, si j'ai un avantage, et si je voulais simplement tout lier à nouveau, aurais-je besoin d'une traversée complète de l'arbre pour une phase de liaison "simple" ?

Je comprends que ce cas d'utilisation n'est peut-être pas actuellement pris en charge par Scons (il suffit de tout lier à nouveau), mais je demande à la fois d'un point de vue pratique et théorique ? Je me rends compte que l'arbre dep mis en cache pourrait être réutilisé avec cette option "ne pas faire d'arbre dep" (je l'ai oublié, cela fait deux ans), et cela fonctionnerait pour certains cas d'utilisation, et ce cas d'utilisation n'est pas de nouveaux fichiers ajoutés, correct ? (npm watch pourrait m'alerter de l'ajout d'un nouveau fichier et je pourrais alors effectuer une actualisation complète de l'arbre dep si je détecte cela... en tapant cette option "utiliser le cache de dépendances" effectuée manuellement par l'utilisateur dans un programme comme npm watch... laissez le programme se soucier de la cohérence, pas de l'utilisateur, et faites-le en "temps réel", au moment où l'utilisateur a enregistré un fichier, donnant beaucoup plus de temps aux scons pour faire sa chose)

Y a-t-il quelque chose dans mon idée qui ne fonctionnerait pas comme une optimisation (pratiquement et théoriquement), et avez-vous d'autres suggestions (qui ne doivent pas garantir une construction parfaite si quelque chose comme npm watch peut s'occuper de tout, c'est bien aussi ) ? Pouvez-vous conseiller s'il vous plaît? Merci!

Pour récapituler, le cas d'utilisation est similaire à celui-ci :

1) lancez un filewatcher comme npm watch sur le répertoire source de godot
2) l'utilisateur enregistre/modifie un ancien fichier
3) scons est immédiatement exécuté pour ce fichier par npm.
4) si la compilation réussit, npm demande à scons d'exécuter l'éditeur de liens et de lier l'exécutable.

4.1) si dep tree est encaissé (une version complète a déjà été exécutée), npm peut demander à l'éditeur de liens de se lier à ce stade avec une version mise en cache de dep tree
4.1) si aucun arbre dep mis en cache n'est détecté, npm watch exécute une compilation complète de godot
4.2) si une invalidation du cache a été détectée, comme l'ajout d'un nouveau fichier, effectuez une traversée complète de l'arbre dep (npm n'utilisera pas l'option "utiliser l'arbre dep mis en cache" avec les scons).

J'espère que cela rendra mon idée un peu plus facile à comprendre, veuillez me faire savoir ce qui ne va pas à ce stade ;D

PS Je crois que c'est la commande qui réduit de 15 secondes les 35 builds incrémentiels nuls, avec ses conséquences "évidentes"... Je veux essentiellement automatiser ce qui est décrit ici (plus ou moins, + faire savoir aux scons quel fichier exact a été modifié si cela l'aide de quelque manière que ce soit (ou cela pourrait l'aider)):

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

Donc quelques petites choses ici (sans ordre particulier, mais j'utilise des nombres parce que yolo

1) Les builds null incrémentiels ne sont fondamentalement rien sous aucun outil qui génère des fichiers ninja. Chrome a, autant que je sache, une version incrémentielle nulle de moins de 2 secondes. Ceci est important, car une chute de 35 secondes à 15 sous un npm watch est toujours très importante par rapport à une version Ninja basée sur meson ou cmake. Ninja fait également la même chose que Scons en ce sens qu'il effectue une reconstruction au cas où la ligne de commande change (make, bien sûr, ne le fait pas)

2) CMake a récemment implémenté la possibilité d'utiliser CONFIGURE_DEPENDS comme argument du système glob. Cela a toujours été déconseillé car des outils tels que xcodebuild et msbuild n'ont historiquement (et actuellement) pas pris en charge la détection des changements de répertoire. C'est, à ma connaissance, une chose que Scons pourrait améliorer, mais je n'ai ni le temps ni la patience de plonger profondément dans le projet de mise en œuvre de cela. Fondamentalement, chaque système d'exploitation met à jour un répertoire lorsque son contenu change, qu'il s'agisse d'un fichier ajouté, d'un fichier modifié ou d'un fichier supprimé. Lorsque vous effectuez des modifications incrémentielles, vous pouvez simplement vérifier quels répertoires ont été modifiés et ne regrouper que ceux lors d'une vérification de reconfiguration. Cela peut réduire le travail effectué car vous ne globalisez pas l'arbre entier, mais des morceaux plus petits. Pour les petits projets, c'est bien. Que cela profite ou non à godot nécessiterait quelques tests et c'est beaucoup de travail pour vérifier si cela aiderait même.

3) Bien qu'il soit agréable de voir que Scons reçoit plus d'attention, je pense personnellement qu'il est préférable pour la communauté dans son ensemble que godot passe à un système de construction plus utilisé. Je ne peux pas penser en dehors de godot d'un grand projet qui utilise Scons. GNOME/GTK est récemment passé à meson (en sautant CMake), KDE est sur CMake depuis un certain temps. Bien qu'il s'agisse de preuves anecdotiques (et donc d'un biais de confirmation de base), je connais plusieurs développeurs C++ qui aimeraient essayer godot mais préféreraient ne plus jamais avoir à toucher à des scons. Supprimer les mauvaises expériences et donc le goût amer laissé dans la bouche des développeurs est difficile, et je souhaite honnêtement le meilleur au projet Scons. Mais je sais que la communauté C++ dans son ensemble déteste déjà les longs temps de compilation. Les builds null incrémentiels longs (ou même les builds incrémentiels longs de 1 fichier) sont un cauchemar dans le monde moderne.

J'ai l'intention de réessayer, mais je pourrais cibler CMake pour cela. Passer de CMake à meson est beaucoup plus facile grâce au script de conversion de meson qui peut faire beaucoup de travail. CMake peut faciliter un peu la gestion des dépendances avec le nouveau module FetchContent. On verra comment ça marche. Je dirai que je suis content que ces scripts codegen aient été déplacés dans des fichiers séparés. Utiliser CMake sera bien, ne serait-ce que parce que passer à un autre standard C++ est aussi simple que target_compile_features(<target> (PUBLIC|PRIVATE|INTERFACE) cxx_std_<number>)

Évidemment, tout élément lié au système de construction sera controversé, mais essayer ne peut pas faire de mal.

Pour être tout à fait honnête, (et cela peut paraître insensible), je n'ai aucune envie de plonger profondément dans le projet Scons pour l'améliorer. Peut-être qu'après 2020, lorsque Python 2.7 sera officiellement mort et que le projet pourra passer à Python 3.5+, il vaudra la peine d'étudier ou d'améliorer, éventuellement avec des opérations asynchrones. Jusque-là, cependant, je préfère ne pas avoir à y toucher.

Peut-être qu'après 2020, lorsque Python 2.7 sera officiellement vraiment mort et que le projet pourra passer à Python 3.5+, cela vaudra la peine d'être étudié ou amélioré

Scons 3 prend en charge Python 3.5+ : https://scons.org/tag/releases.html .

Je ne comprends pas vraiment comment on peut tant détester Scons et aimer le désordre de configuration qu'est CMake, où il est même difficile de définir ses propres paramètres de construction si vous êtes un utilisateur, difficile de comprendre quelles sont les options et leurs types et quoi sont des définitions internes, cela ne m'a fait que souffrir, et j'étais en fait soulagé que Godot ne l'ait pas utilisé.

Dans tous les cas, si vous pensez que ce sera une meilleure solution, continuez et essayez, je pourrais finir par changer d'avis sur CMake.

où il est même difficile de définir vos propres paramètres de construction si vous êtes un utilisateur,

Si cela est demandé, alors CMake est mal utilisé. Tous les paramètres de la chaîne d'outils doivent être dans un fichier de chaîne d'outils et toutes les configurations spécifiques au projet sont transmises via des indicateurs (ou gui ou modifiez le fichier de cache ou autre). Tout est documenté et tapé, même les auteurs du projet peuvent bien documenter et taper leur configuration exposée. Vous devriez lire CGold et les normes CMake modernes.

@Faless personne ne nie que le langage CMake est terrible. Mais la mise en œuvre est la meilleure de sa catégorie. J'ai envisagé la possibilité d'écrire un transpileur à partir d'une meilleure langue pour atténuer le problème.

@ OvermindDL1 aime la suggestion de lire CGold.

Si cela est demandé, alors CMake est mal utilisé

Eh bien, je suppose que tous les programmes que j'ai rencontrés le faisaient mal alors.

Pour être honnête, je déteste devoir changer de drapeau via -DI_LOVE_CMAKE_AND_MAKE_DEFINES_LONG=on (vraiment ? on ?). Sans oublier l'idée d'éditer le fichier cache O_o . Ou que, si je veux changer un indicateur, je finis par devoir supprimer le dossier de construction et recommencer à zéro (parce que, vous savez, le cache diffère !)... tant pis pour les constructions incrémentielles...

EDIT: De plus, une chose que j'ai vraiment aimé à propos de Scons (dans Godot au moins, et cela pourrait être possible avec d'autres systèmes de construction bien sûr), c'est que je n'ai lu aucune norme ou doc, je lance juste scons -h dans le dossier Godot

95% des fichiers de build que j'ai vus sur GitHub sont faux. Les gens deviennent paresseux à propos des systèmes de construction et suivent les pratiques du culte du fret pour bricoler quelque chose.

@isaachier , juste comme métrique, pourriez-vous fournir 2 exemples d'un mauvais et bon fichier CMake ? Comment considéreriez-vous ceci : https://github.com/ARMmbed/mbedtls/blob/development/CMakeLists.txt ?

Mieux que la plupart que j'ai vu. Néanmoins, si vous n'utilisez pas CMake >= 3.0, alors votre expérience avec CMake n'est pas moderne.

Eh bien, je suppose que tous les programmes que j'ai rencontrés le faisaient mal alors.

J'ai tendance à le voir bien fait de nos jours.

Pour être honnête, je déteste devoir changer les drapeaux via -DI_LOVE_CMAKE_AND_MAKE_DEFINES_LONG=on (vraiment ? on ?). Sans oublier l'idée d'éditer le fichier cache O_o . Ou que, si je veux changer un indicateur, je finis par devoir supprimer le dossier de construction et recommencer à zéro (parce que, vous savez, le cache diffère !)... tant pis pour les constructions incrémentielles...

Vous n'êtes pas obligé d'utiliser on , vous pouvez utiliser true , 1 , et une variété d'autres choses. C'est pour que vous puissiez choisir un nom booléen approprié qui s'accorde bien avec le nom du drapeau.

Et vous ne devriez jamais avoir besoin de reconstruire le dossier de construction si vous modifiez les options, cmake est exceptionnellement bon pour reconstruire si nécessaire.

Cependant, tous ceux qui touchent aux systèmes de construction C/C++ devraient lire CGold ainsi que le manuel officiel de CMake. Il est vraiment facile à utiliser CMake droit, il est souvent beaucoup plus court aussi bien. Les anciennes méthodologies CMake2 ne doivent pas être utilisées. Vraiment cependant, toute personne qui dépend d'une version CMake 2.x fait absolument les choses mal (n'utilise pas correctement les cibles et les chaînes d'outils, ne définit pas correctement les options, etc... etc...).

Merci pour les explications, même si je reste sceptique, j'ai hâte de voir comment cela fonctionnerait pour Godot :).

@slurps-mad-rips Votre article avec l'exemple de code supposé CMake pour activer le mode C++11 est entièrement non standard CMake pour diverses raisons, y compris, mais sans s'y limiter :

• Définition de variables non exposées.
• Arguments de la chaîne d'outils définis dans un fichier autre que la chaîne d'outils.
• Absolument pas comment vous faites quelque chose comme activer le mode C++11.
• Inefficace.

Étant donné le code de méson auto-décrit comme simplifié dans ce message 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)

L'équivalent simplifié (en ce sens que vous pouvez également ajouter plus de propriétés) CMake serait :

set_target_properties(godot PROPERTIES CXX_STANDARD 11)

Et cela garantira que la chaîne d'outils utilisée sait qu'elle doit définir ce mode (et vous pouvez spécifier comment gérer les échecs si vous utilisez un compilateur qui ne le prend pas également en charge). En supposant que des indicateurs de ligne de commande spéciaux spécifiques au compilateur dans le fichier de construction soient d'une forme extrêmement médiocre, car ils ne devraient exister que dans les fichiers de la chaîne d'outils et le fait que l'exemple de meson montré dans le post précédent spécifie en fait des arguments spécifiques signifie essentiellement que vous codez en dur les compilateurs pris en charge.

Considérant qu'il existe un fichier CMake Toolchain pré-construit pour à peu près n'importe quelle chaîne d'outils à laquelle vous pouvez penser (y compris toutes les normes de MSVC de diverses variétés, GCC/Clang, android, iOS, emscripten, etc... etc...) vous ne devrait pas réinventer la roue. Si l'utilisateur qui compile quelque chose comme godot veut utiliser son propre compilateur personnalisé avec des arguments de ligne de commande uniques (comme prendre le compilateur d'Intel ou peut-être une puce dédiée ou juste un simple RPi), alors le script de construction ne devrait pas avoir besoin de s'en soucier ou besoin de modifications (le code peut bien sûr, mais de manière optimale, il ne le devrait jamais non plus, car CMake peut lui dire ce qui est pris en charge via les définitions) et l'utilisateur peut fournir son propre fichier de chaîne d'outils personnalisé pour la construction à utiliser.

EDIT : Et ne négligez jamais le soutien généralisé. Je ne trouve rien sur la capacité de meson à générer des fichiers de projet pour KDevelop (l'IDE que j'utilise, qui utilise de manière intéressante CMake comme format de construction, j'utilise parfois CLion au travail, il utilise également CMake), où presque tous les IDE sortent ( même Visual Studio !) peut maintenant ouvrir des projets CMake nativement (en plus de CMake pouvant générer des projets pour la plupart des IDE directement si vous le souhaitez).

@OvermindDL1

Ce n'est pas du tout un CMake non standard. L'exemple de code cible CMake 3.0, une version dans laquelle CXX_STANDARD n'existe pas. Vous pouvez facilement voir à partir d' ici que vous utilisez target_compile_features avec cxx_std_ et le numéro de la norme. C'est la nouvelle et moderne façon cmake de définir la version standard. set_target_properties est une ancienne approche par cible.
En fait, le code exact tiré de la documentation de

target_compile_features(mylib PUBLIC cxx_std_11)

Cependant, CXX_STANDARD ne définit -stdlib=libc++ et de le transmettre au compilateur via une expression génératrice. Il n'y a rien impliquant des variables non exposées à ce sujet.

De plus, je n'apprécie pas que vous ayez laissé un commentaire pour apporter des corrections à un commentaire que j'ai fait il y a des

CMake 3.0 est assez ancien pour ne plus être pris en charge (10 juin 2014). Personne ne devrait exécuter moins que CMake 3.10 actuellement, bien qu'il soit préférable de rester à jour avec CMake 3.12 pour le moment.

Et oui, l'exemple que vous avez donné est entièrement déconseillé (je pense que même CGold mentionne ne pas le faire).

Et oui, je voulais dire target_compile_features. ^.^;

Cependant, CXX_STANDARD ne définit pas la prise en charge de libc++ pour clang car clang utilise libstdc++ par défaut sur Linux à moins d'être configuré (et il n'est jamais configuré pour utiliser libc++ par défaut sur la plupart des distributions Linux, car cela provoquerait des erreurs d'éditeur de liens et des problèmes ABI). La seule façon de le faire à ce stade est de vérifier si le compilateur prend en charge -stdlib=libc++ et de le transmettre au compilateur via une expression génératrice. Il n'y a rien impliquant des variables non exposées à ce sujet.

Les chaînes d'outils actuelles le font toutes très bien pour le clang, du moins avec C++14 car c'est avec cela que je compile (et quelques C++17).

De plus, je n'apprécie pas que vous ayez laissé un commentaire pour apporter des corrections à un commentaire que j'ai fait il y a des mois, d'autant plus que je ciblerai CMake sur Meson lors de ma prochaine tentative. Il manque de tact, et à mon avis n'ajoute rien à la conversation.

Je m'excuse, je n'ai pas remarqué la date alors que je lisais le backlog (et il y a beaucoup de backlog ici). Je viens de remarquer quelque chose qui semblait terriblement faux pour tout type de suggestions modernes d'après ce que j'ai vu depuis quelques années maintenant et je n'ai vu aucune correction dans les messages peu de temps après, je voulais donc que les informations incorrectes ne se propagent pas. :-)

La seule façon de le faire pour le moment est de vérifier si le compilateur prend en charge -stdlib=libc++ et de le transmettre au compilateur via une expression génératrice.

Cependant, oui, c'est le travail du fichier de la chaîne d'outils, qui ne devrait absolument jamais apparaître dans un fichier de construction, jamais .

Il n'y a rien impliquant des variables non exposées à ce sujet.

Je faisais juste référence aux variables qui sont définies puis utilisées ailleurs dans des emplacements uniques, ce qui est déconseillé dans CGold, entre autres, pour diverses raisons.

CMake 3.0 est assez ancien pour ne plus être pris en charge (10 juin 2014). Personne ne devrait exécuter moins que CMake 3.10 actuellement, bien qu'il soit préférable de rester à jour avec CMake 3.12 pour le moment.

Ils ne devraient pas, et pourtant certains endroits le sont. Pour un moteur de jeu qui essaie de rester à jour et avec les dernières technologies, rester sur le dernier CMake est bien. Cependant, je suis plus que conscient des projets extrêmement actifs bloqués sur des versions plus anciennes telles que 3.5 et dans certains cas 3.4. En fait, certaines bibliothèques C bien connues ciblent toujours CMake 2.8 (voir : SDL2, libssh2, libgit2, etc.).

Cependant, oui, c'est le travail du fichier de la chaîne d'outils, qui ne devrait absolument jamais apparaître dans un fichier de construction, jamais.

Faire cette hypothèse (que les fichiers de la chaîne d'outils sont bien écrits et couvrent tous les systèmes possibles et toutes les versions de CMake) pose problème dans l'écosystème C++ général actuel. Lors de l'utilisation de clang, l'option de compilation pour libstdc++ ou libc++ (en particulier lorsqu'elle est utilisée via un appel FetchContent ) doit être fournie par la bibliothèque. CheckIncludeCXX et CheckCXXCompileFlag sont toujours nécessaires même pour certains drapeaux qui n'existent pas sous GCC mais existent sous Clang (et vice versa). Le principal problème ici est que les interfaces du compilateur ont beaucoup divergé et au lieu que les fournisseurs passent du temps à faciliter les options de compatibilité ou même à discuter d'une interface commune, ce comportement nous est imposé, le développeur, alors que tout ce que nous voulons faire est d'écrire du code. Croyez-moi, personne sur cette planète n'est plus contrarié que moi par l'état des systèmes de build C et C++ et la gestion des dépendances, mais le pragmatisme pour les bibliothèques existantes sur CMake est nécessaire. La bonne chose à propos du passage d'un système de construction à CMake est que nous pouvons commencer avec les fonctionnalités les plus récentes et les plus performantes. Le problème devient la stagnation du système de construction parce que personne ne veut y toucher (à l'exception de cette âme courageuse qui a lancé les scripts de génération de code dans des scripts séparés), mais un certain travail serait nécessaire pour s'assurer que cela ne devienne pas incontrôlable (ce qui sera le cas parce que... je veux dire que c'est un système de build. Ils le font toujours)

Je dois être le seul gars qui aime vraiment écrire des scripts de build, en particulier dans CMake ;).

Faire cette hypothèse (que les fichiers de la chaîne d'outils sont bien écrits et couvrent tous les systèmes possibles et toutes les versions de CMake) pose problème dans l'écosystème C++ général actuel. Lors de l'utilisation de clang, l'option de compilation pour libstdc++ ou libc++ (en particulier lorsqu'elle est utilisée via un appel FetchContent) doit être fournie par la bibliothèque.

De telles choses devraient être des propriétés transmises à la chaîne d'outils sur laquelle la chaîne d'outils peut ensuite agir.

De plus, si vous avez une configuration très unique, il est tout à fait raisonnable d'inclure des fichiers de chaîne d'outils, par exemple pour une version Android très personnalisée (bien que l'ensemble étendu de chaînes d'outils cmake ait couvert presque tout ce dont j'avais besoin jusqu'à présent).

Le problème devient la stagnation du système de construction parce que personne ne veut y toucher (à l'exception de cette âme courageuse qui a lancé les scripts de génération de code dans des scripts séparés), mais un certain travail serait nécessaire pour s'assurer que cela ne devienne pas incontrôlable (ce qui sera le cas parce que... je veux dire que c'est un système de build. Ils le font toujours)

C'est en fait un excellent point pour choisir CMake maintenant, il a un ensemble de normes bien définies à suivre qui fonctionnent très bien maintenant après avoir fait face à plus d'une décennie d'expérience antérieure, à la fois bonne et mauvaise.

Je dois être le seul gars qui aime vraiment écrire des scripts de build, en particulier dans CMake ;).

Je l'apprécie par rapport aux alternatives, bien sûr, même si j'y ai écrit assez longtemps pour que cela ait du sens pour moi, bien que cela ne signifie certainement pas que ce serait pour tout le monde. ^.^;

J'ai utilisé beaucoup de systèmes de construction différents au fil des ans. Celui qui a eu le plus de sens pour moi récemment est CMake, mais je peux certainement voir l'attrait de SCons et à quel point il est flexible.

Même si SCons n'est pas parfait (quel est le système de build ?), il peut être suffisant.

• Fournit-il les fonctionnalités requises ?
• Combien de frais généraux cela crée-t-il ?

Si SCons obtient un score « assez bon » pour les deux points, conservez-le.

Est-ce que l'un d'entre vous proposant le remplacement de SCons par quelque chose d'autre a réellement pris l'effort d'apprendre comment fonctionne le système de construction de Godot ?

À titre indicatif, c'est incroyablement complexe et je ne pense pas qu'il y ait beaucoup (ou aucun) de projets utilisant la construction CMake pour autant de plates-formes et permettant d'avoir plusieurs cibles de construction configurées/compilées en même temps comme nous le faisons.

Tous les efforts de ceux qui ont dit "Je vais porter le système de construction de Godot vers quelque chose d'autre" ont lamentablement échoué jusqu'à présent lorsqu'ils ont réalisé la complexité de ce dont SCons s'occupe.

Pour moi, c'est de loin le meilleur outil pour le travail. Rien n'en est même proche. Si vous vous plaignez du temps de compilation de base (qui n'est que de 4/5 secondes sur un système moyen à haut de gamme avec SSD), vous devriez d'abord essayer de comprendre tout ce que Godot fait lors de la construction et voir comment il fonctionnerait dans CMake ou autre chose .

J'ai jeté un œil. Je ne suis pas convaincu que ce soit annulable dans CMake ou ailleurs. Mais je suis aussi paresseux ;). Nous allons voir ce qui se passe.

Comme quelqu'un qui a fait le port de bazel. J'ai pu arriver au point où l'éditeur Godot a commencé sans icônes.

Je suis presque sûr que CMake peut atteindre ce point.

PS. Le projet concurrent le plus proche avec un grand nombre de plates-formes est Urho3d.

J'ai reproduit mon résultat bazel sur cmake.

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

Supposons que Visual Studio 2017 soit installé.

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() {
}

Installer 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

S'il vous plaît, jouez avec. L'éditeur a les mêmes problèmes que la version bazel (pas d'icônes), mais cet exemple peut vous être utile.

Noter

• Les icônes fonctionnent à partir de 71175b45f819e7cc5e4368dbf3e42abdd19af542
• Travail de Visual Script et GDscript

@fire Merci pour cela. Je vois de nombreux points à améliorer qui faciliteraient la maintenance de ces fichiers CMake (et le temps passé à ajouter de nouvelles fonctionnalités ou des indicateurs de compilateur). Je pourrais m'attaquer à cela le week-end prochain cependant, programme en attente.

Super travail @fire. Heureux de voir que quelqu'un ici peut produire quelque chose dans plus d'un système de construction : smile:.

Petite mise à jour. J'ai eu un temps d'arrêt aujourd'hui pour m'attaquer à la construction du travail de charge les chaînes de modèle et cela peut rendre la vie un peu plus facile, au lieu d'avoir à traiter des chaînes, les ajouter à une liste, puis traiter plus de chaînes et les ajouter à une liste, etc. etc.

Idéalement, les scripts de génération de code devraient pouvoir être exécutés comme s'ils étaient des exécutables sans connaissance de la construction. Tant que les fichiers appropriés leur ont été transmis, nous serions bien de procéder au portage complet sur n'importe quel autre système de build.

@slurps-mad-rips Extraire cela de votre système SCons est une bonne idée même dans SCons. Vous pouvez raccrocher le GIL en ayant trop de logique en cours et nuire à vos performances de construction. Parfois, cela conduit à des conditions de concurrence fermées/ouvertes de fichiers lors de la construction en parallèle (bien que souvent résolues en ouvrant le fichier avec dans un contexte).

Bonjour à tous,

Je vais utiliser cet espace pour tenir les gens au courant du port de CMake. Si demandé, je ferai un problème séparé et garderai une trace des changements là-bas, bien que ce soit un domaine agréable étant donné qu'il a un énorme arriéré de discussions et je pense que ce serait une perte de perdre autant de contexte.

Je digresse. Je vais devoir faire une pause dans le portage de CMake la semaine prochaine pendant que j'assiste à une conférence, mais vous pouvez voir les efforts de ma première tentative de portage ici . S'il vous plaît, gardez à l'esprit que je vais tirer pour rester 1:1 avec la branche principale actuelle, et en tant que tel, je forcerai les changements à mesure qu'ils arrivent afin que je puisse garder une rebase. À mesure que j'approche de la stabilité, je déposerai une demande d'extraction pour que les rebases soient plus faciles à utiliser, ainsi que pour faciliter les commentaires sur les modifications ou les questions. Je pense que ce portage vers CMake est non seulement faisable, mais à tout le moins, cela permettra à une personne de plus (moi) de bien connaître la façon dont Godot est réellement construit et construit et je pourrais peut-être le mettre en mots pour que d'autres puissent obtenir une vue plongeante sur le système de construction. Ce port pourrait également faciliter le flux de travail de tout le monde à long terme, en particulier avec les versions. Je ne vais pas mentir, avoir le CONFIGURE_DEPENDS globbing de fichiers mélangés avec Ninja est en fait assez sympa.

Une dernière chose, je vous suggère fortement de jeter un coup d' œil aux modules d' aide

Avez-vous pu mettre à jour vers la dernière version 3.1 alpha ? L'alpha pourrait être une bonne cible. Actuellement en train d'essayer le build.

Le titre de ce numéro est Envisagez de déplacer le système de construction vers Meson . Je pense qu'il est inapproprié d'avoir une discussion sur CMake ici. La discussion sur CMake devrait avoir son propre problème. La comparaison de Meson par rapport à n'importe quoi d'autre est très bien.

@zaniar Il y a eu beaucoup de discussions dans ce fil concernant les systèmes de construction en général. Ce n'est pas parce que le titre n'a pas été mis à jour que nous allons soudainement créer un nouveau problème et perdre tout ce contexte de discussion et tout recommencer. Je pense qu'il est inapproprié de nous demander de jeter soudainement plusieurs mois de discussions.

@fire J'ai été occupé par le travail ces dernières semaines, j'ai un gros délai pour vendredi, et après cela, j'aurai peut-être le temps de mettre ma fourchette à jour. J'ai quelques changements localement j'ai oublié de pousser mais je n'ai pas le temps en ce moment. (Entre ce port de système de construction, mon fork de gnu m4, 15 propositions que j'écris pour la réunion des normes C++ de San Diego et CppCon la dernière semaine du mois, je suis absolument débordé, et je n'ai personne à blâmer mais moi même)

Oui, Meson était la cible de discussion d'origine, mais je pense qu'il est assez naturel que d'autres systèmes de construction aient été évoqués et discutés depuis, et il est probablement logique de garder la discussion dans ce problème ici au lieu de l'étendre, comme @slurps -mad-rips a dit.

Je suis d'accord avec le passage à CMake. Il a beaucoup de soutien avec ses chaînes d'outils. Les builds Android, par exemple, deviennent très faciles par rapport à ce que fait Godot dans son fichier SCsub qui me semble « non maintenable ».

En tant que projet open source, Godot devrait opter pour des solutions faciles à maintenir et que les contributeurs sont plus susceptibles de connaître et de pouvoir contribuer.

De plus, je pense que cela est important pour l'adoption de GDNative. Quel que soit l'outil de construction utilisé, il doit y avoir un exemple ou un projet standard avec un script de construction facilement modifiable qui prend en charge la construction pour toutes les plateformes, y compris iOS, Android, etc.

De plus, les modules normaux devraient pouvoir être compilés en tant que bibliothèques partagées. Ceci est lié à #19486 afin que le moteur puisse être séparé en plusieurs composants téléchargeables.

Je m'attaque en fait à ceux-ci. Je n'ai pas poussé mes changements depuis un moment parce que j'ai été occupé avec CppCon, la prochaine réunion sur les normes C++, et nous préparons une version la semaine prochaine au travail. Autant dire que je n'ai pas eu beaucoup de temps pour terminer le portage, mais la plupart de mon temps va être consacré à extraire les scripts python qui génèrent du code C++ à l'avenir. J'espère reprendre le travail sur mon port ce week-end. J'évalue actuellement s'il faut acquérir automatiquement des dépendances tierces et appliquer les correctifs stockés dans le référentiel ou non. Une question que je n'ai pour les développeurs de base est le degré d' ouverture , ils seraient à briser toutes les third_party prises en pension de la principale mise en pension et dans leurs propres référentiels sur l'organisation. Je compte assez fortement sur FetchContent dans mes propres projets, et j'aimerais actuellement pouvoir le faire pour ces dépendances tierces qui ont été légèrement fourchues. Cela me permettrait également de travailler sur chacun à son tour pour nettoyer leurs fichiers cmake tout en apportant des modifications incrémentielles au référentiel principal une fois que chaque bibliothèque tierce est portée.

De plus, il convient de noter que j'essaie également de modulariser le moteur lui-même, afin que ces composants puissent techniquement être mis à jour séparément les uns des autres si quelqu'un le souhaitait. Cela pourrait résoudre le problème mentionné par

Enfin, j'ajoute la prise en charge de quelques outils de construction supplémentaires pour les développeurs principaux s'ils se trouvent sur le système. Des choses comme clang-format, clang-tidy, ccache ou sccache, distcc, clang-check, address sanitizer, ubsanitizer, thread asinizer, etc. Ce sont principalement des linters (et peuvent faire exploser la tête de certaines personnes avec les avertissements et diverses erreurs qu'ils' avez détecté) mais ils seront facultatifs à activer. À tout le moins, l'utilisation de sccache ou de ccache apportera une certaine amélioration de la construction lors du basculement entre les versions et vice versa. Attendre la sortie de CMake 3.13 serait bien car cela résoudrait une partie du travail fastidieux sur lequel j'ai dû compter, mais l'important est que je le configure de sorte que le flux de travail actuel de "démarrage" soit de continuer à exécuter pip install via Python 3.5 ou une version ultérieure, mais ce sera à l'intérieur d'un virtualenv afin que les gens n'aient pas à se soucier de l'environnement de leur système. (Cela permettrait également à d'autres d'expérimenter l'utilisation de bibliothèques python supplémentaires en tant que dépendances pour divers scripts de génération de code et de ne pas avoir à se souvenir de les désinstaller plus tard)

Quoi qu'il en soit, désolé pour la mise à jour soudaine d'infos, vous tous. Je suis déterminé à terminer ce port, mais la vie s'est entravée récemment 😅

Je m'appuie assez fortement sur FetchContent dans mes propres projets, et je souhaite actuellement pouvoir le faire pour ces dépendances tierces qui ont été légèrement fourchues.

Vous pouvez également utiliser Hunter et créer un référentiel de code spécifique à godot (un dépôt git spécial, comme sur github par exemple) et accéder à toutes les dépendances de cette façon car il gère la construction, la mise en cache, etc. (ou soumettez toutes les dépendances au référentiel de packages Hunter "principal" et utilisez-le directement). Hunter n'est qu'un seul fichier cmake (HunterGate.cmake) et un appel à celui-ci pour acquérir les informations du référentiel de packages (qu'il s'agisse d'un fichier officiel ou personnalisé).

Une humble demande : le fil de commentaires de ce problème est devenu énorme - quelqu'un qui l'a suivi pourrait-il résumer la discussion générale jusqu'à présent dans un commentaire (et peut-être qu'il pourrait être lié à partir du message initial de

Bonjour à tous. Je prévois d'utiliser Godot comme prochain moteur pour faire un petit jeu.

J'ai vu cette conversation et en tant que personne qui a de l'expérience à la fois dans CMake et Meson (et autotools, tup, plain make, waf, SCons, essayer des projets complets dans tous ces outils...) je voulais donner mon avis.

Les systèmes que j'ai utilisés plus intensivement ont été Autotools, CMake et Meson. J'utilise Meson et CMake depuis des années, car j'ai déjà supprimé tous les autres systèmes de construction dans les configurations de production.

Avantages de cmake

• Générateurs de projets matures si vous vous souciez de Visual Studio (je pense que Meson le supporte bien de nos jours mais n'a pas essayé ces derniers temps) et surtout XCode (il manque certainement plus ici).
• Une adoption plus large, plus de support dans les IDE
• Adoption plus large -> plus facile d'obtenir des contributions (bien que Meson soit un jeu d'enfant à apprendre, je dois dire)

Avantages de Méson

• de nombreuses cibles utiles par défaut : désinfectants, unity builds gratuitement, en-têtes précompilés gratuitement, couverture gratuite...
• la documentation donne un coup de pied au cul de la documentation CMake : http://mesonbuild.com/
• J'ai trouvé la compilation croisée beaucoup plus facile
• Meson a une façon évidente de faire chaque chose

Lequel choisirais-je ? Je choisirais Meson si la compilation croisée doit être intensive et que vous vous souciez des temps de compilation rapides (les versions Unity et les en-têtes précompilés sont pris en charge par défaut).
Je considérerais CMake car c'est la norme et les contributions sont peut-être importantes pour l'équipe. Je choisirais moi-même Meson personnellement, mais ce n'est qu'un avis personnel, car je trouve l'outil juste meilleur et cela me fait gagner du temps (script CMake, gestion de l'espace, expressions génératrices, etc... Je vous regarde).

Désolé pour cette auto-promotion éhontée ci-dessous, mais je pense que le contexte le supplie.

J'ai une petite série d'articles sur Meson plus ou moins basique ici si quelqu'un est curieux (4 articles) :

• 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

J'ai une réponse (un peu obsolète) sur les systèmes de build dans StackOverflow :

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

Juste mes deux cents :)

@germandiago C'est un excellent article - je suis ce problème depuis un certain temps et ce serait merveilleux si je pouvais travailler avec godot + CLion, qui est malheureusement uniquement CMake.

Oui, la plupart des IDE modernes sont soit uniquement CMake, et/ou certains systèmes de construction personnalisés et/ou des « appels bruts » qui perdent beaucoup de fonctionnalités. CMake est vraiment devenu un standard, qu'il soit mérité ou non.

@dorkbox si je peux obtenir ces modifications sur lesquelles je travaille, vous pourrez certainement travailler dans un workflow CLion (cmake + ninja).

@germandiago

Je suis actuellement ami (plus ou moins 😛), avec l'auteur de meson depuis la CppCon 2018. Nous nous sommes retrouvés tous les deux sur le même papier pour la prochaine réunion concernant les modules intitulés "Remember the Fortran", et je vais présenter son papier lors de ladite réunion (c'est la semaine prochaine, en fait !), et nous étions également sur le même panel de systèmes de construction à CppCon.

J'aimerais utiliser Meson. Si vous lisez plus haut dans le fil, j'avais essayé un port meson, mais les choses étaient trop intégrées avec Scons à l'époque. Je suis toujours en train de retirer les scripts de génération de code actuels pour qu'ils soient des scripts « exécutables » distincts afin que si, à l'avenir, un passage à Meson ne soit pas hors de question. Cependant, c'est un travail lent, et j'ai commencé à écrire quelques modèles jinja pour aider à la génération de code afin que les scons puissent être entièrement supprimés. Cela dit, alors que mon fork public est obsolète, celui que j'ai à la maison est un peu plus avancé (et synchronisé avec un fork privé). Le travail m'a malheureusement gêné, et San Diego va malheureusement me « voler » plus de temps. Après cela, cependant, je devrais être libre de supprimer certaines des expériences locales que j'ai sur ma fourche privée et enfin de revenir sur le train godot cmake. Je m'engage à faire en sorte qu'une demande d'extraction complète puisse être envoyée sans également perturber massivement le processus de flux de travail actuel.

(Soit dit en passant : merci à tous pour la patience que vous avez eue pendant que je travaille sur ce sujet. Je sais que cela fait un moment que je l'ai commencé, mais je représente maintenant mon employeur pour l'organisme national américain pour le comité des normes C++, donc mon emploi du temps a été un peu plus complet ces derniers temps, d'autant plus que nous avons abordé des sujets importants tels que les modules, les coroutines et les gammes)

Oui, la plupart des IDE modernes sont soit uniquement CMake, et/ou certains systèmes de construction personnalisés et/ou des « appels bruts » qui perdent beaucoup de fonctionnalités. CMake est vraiment devenu un standard, qu'il soit mérité ou non.

Un outil utile possible pour utiliser meson avec des IDE :

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

Cela fait penser à l'IDE qu'il utilise CMake, mais utilise vraiment meson sous le capot.

Un peu de contexte : j'ai été un grand partisan de CMake pendant de nombreuses années (10 ?), mais je suis tombé amoureux de meson l'année dernière. Meson semble avoir été écrit dans le but d'avoir les fonctionnalités utiles de CMake tout en corrigeant/prévenant de nombreux désagréments de CMake. Un obstacle auquel je suis actuellement confronté pour l'adoption de meson dans un projet est le support IDE. Je viens de découvrir l'outil ci-dessus, alors peut-être que cela vous aidera.

Tous les systèmes de construction ont leurs principaux défauts, plus que cela, il n'y a aucune raison de changer cela d'un point de vue technique, qu'il s'agisse de scons, d'autotools, de cmake, de meson ou de tout ce que votre religion est make vs ninja. Je pense que ce serait formidable de fermer tous les autres bogues de modification du système de construction en tant que doublon de celui-ci.

<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

Prouvez que vous avez tort @slurps-mad-rips :).

Un gorille de 800 livres dans la pièce qui n'a pas encore été mentionné. L'un des titres de gloire de Godot est la compatibilité multiplateforme. Il devrait s'ensuivre que tout système de build vers lequel il est possible de migrer devrait être disponible et testé sur toutes les plates-formes ciblées par Godot. Quiconque est à l'origine d'une telle migration devrait être enclin à tester la migration sur toutes les plates-formes prises en charge, ou au moins faire partie d'une équipe qui le fait. Sinon, je considérerais une telle démarche comme contraire à la philosophie de Godot et généralement juste une mauvaise idée.

@lazybullfrog J'ai accès à environ 5 machines distinctes pour le bureau et à plusieurs appareils mobiles. Une partie de mon portage sur cmake consiste à m'assurer qu'il existe des chaînes d'outils cmake disponibles pour toutes les plates-formes actuelles.

@slurps-mad-rips Est-ce que l'un de ces Haiku? Sinon, je serais prêt à aider à tester. Merci.

Une partie de mon portage sur cmake consiste à m'assurer qu'il existe des chaînes d'outils cmake disponibles pour toutes les plates-formes actuelles.

N'oubliez pas non plus que si vous avez besoin de chaînes d'outils cmake pour une plate-forme, il y en a probablement une préconstruite sur https://github.com/ruslo/polly et s'il n'y en a pas, vous devriez la PR. :-)

@slurps-mad-rips Comment ça se passe ? J'ai remarqué que vous aviez mis à jour le code le 14 janvier. J'ai essayé de compiler sous Windows mais il n'a pas trouvé pkgconfig.

@fire life a décidé de me lancer quelques balles courbes et je devais m'en occuper. Des trucs personnels, malheureusement. Je me suis concentré sur le travail et j'ai terminé la bibliothèque IXM que j'utilise pour réduire la quantité de travail qui serait copiée dans godot. Heureusement, je prends des vacances dans une semaine (je pars à Kona pour la réunion ISO WG21 pour ce trimestre ce week-end) donc j'aurai du temps libre pour travailler dessus, et (j'espère !) j'aurai une version fonctionnelle pour macOS, Linux et Windows soon™. Android et iOS, suivis de FreeBSD et Haiku (désolé @lazybullfrog , bien que vous soyez plus que bienvenus pour tester tôt/souvent) seront ma prochaine priorité après cela.

Le plus gros morceau de travail/bloqueur jusqu'à présent a été d'extraire les scripts python dans des outils "installables" qui sont séparés de Scons et exécutés comme des processus. La saisie réelle des dépendances, des paramètres, etc. a été plus facile en comparaison.

@slurps-mad-rips, la vie m'a aussi lancé quelques balles courbes. Peut-être devrions-nous créer une équipe de baseball. ??

Heureusement, l'une de ces boules courbes depuis mon dernier commentaire était un Xeon à 8 cœurs avec 32 Go de RAM avec Haiku et FreeBSD installés. Peut-être que bientôt j'aurai un peu de temps pour aider à tester les deux.

Je suis en fait ravi que ces deux plates-formes retiennent l'attention. Hâte de tester bientôt.

Je pense qu'il est raisonnable d'avoir plusieurs systèmes de construction. Peut-être un système de construction officiel qui est bien pris en charge et les autres fournis sur une base « vous le comprenez ». Les utilisateurs voudront quand même utiliser leur propre système de construction, alors pourquoi ne pas regrouper leur travail en un seul endroit ?

Je serais prêt à contribuer à un portage de Bazel si les choses se passent ainsi.

Je pense qu'il est raisonnable d'avoir plusieurs systèmes de construction. Peut-être un système de construction officiel qui est bien pris en charge et les autres fournis sur une base « vous le comprenez ». Les utilisateurs voudront quand même utiliser leur propre système de construction, alors pourquoi ne pas regrouper leur travail en un seul endroit ?

En tant que packageur Linux, j'ai vu des centaines de projets avec différents systèmes de construction. J'en ai vu quelques-uns qui avaient plusieurs buildsystems disponibles. Je n'en ai jamais vu un où ce n'était pas un gâchis complet, en particulier lorsque les systèmes de construction alternatifs ont été fournis par des contributeurs pour la première fois "veuillez ajouter CMake c'est tellement cool" qui ont ensuite disparu du projet et que les mainteneurs n'ont pas pris la peine de le mettre à jour.

Il n'y a aucune valeur à supporter plusieurs systèmes de construction, et je ne fusionnerai aucun PR allant dans cette direction. Je suis l'un des principaux mainteneurs de buildysytem, ​​et je ne veux certainement pas avoir le fardeau de maintenir des alternatives chaque fois que nous devons changer quelque chose.

Nous avons actuellement un système de construction qui fonctionne pour tout le monde et qui est bien pris en charge, et aucune intention de changer. Si quelqu'un veut vraiment étudier d'autres options, n'hésitez pas, et si le résultat final fonctionne également pour tout le monde, peut être bien pris en charge et apporte une valeur ajoutée sans gros inconvénients, nous l'envisagerons.

Si quelqu'un veut _vraiment_ étudier d'autres options, n'hésitez pas, et si le résultat final fonctionne également pour tout le monde, peut être bien pris en charge et fournit une valeur ajoutée sans gros inconvénients, nous l'envisagerons.

C'est ce que j'ai fait avec mon port CMake. Actuellement, un changement de fichier sans opération ou unique sous scons prend plus de 10 secondes sur ma machine actuelle (qui a 64 Go de RAM, un processeur comparable, etc.) Avec ninja + cmake, l'ensemble du processus de configuration + génération prend moins de temps, et le ninja la construction se termine en moins de 0,2 seconde dans une construction sans opération (sous Windows, où le lancement d'un processus est coûteux). Je suis également capable d'utiliser l'outil sccache de mozilla s'il est installé, et cela a été extrêmement utile pour éditer les parties de codegen/exécuter une version régénérée à partir de zéro pour m'assurer que rien ne dépend de mon environnement local.

la plupart de mon temps a été consacré à l'extraction des scripts de génération de code dans des scripts python qui pourraient s'exécuter seuls. Si c'était la seule chose fusionnée dans godot, mon temps passé là-dessus n'aurait pas été une perte totale. Il résout également le hack run_in_subprocess qui existe actuellement pour résoudre les problèmes sur Windows avec la parallélisation.

Je viens de rentrer de mon voyage et j'ai pu faire un peu de travail. À l'heure actuelle, j'ai encore besoin de copier quelques fichiers à partir d'une exécution manuelle de scons, mais j'ai réduit les sources générées au fil du temps. Les en-têtes license.gen.h et method_bind.inc sont actuellement ma plus grande cible, mais je prends quelques jours pour gérer le décalage horaire + le travail avant de les aborder.

(je vais aussi juste envoyer un cc à

D'après mon expérience, Meson est totalement foutu lors de la construction d'Android sur Windows, je ne peux tout simplement pas le faire fonctionner pour compiler l'une des bibliothèques tierces qui l'utilise (libepoxy). Et je pense que c'est trop lié à des trucs concrets de compilateur.

Tout ce que je désire, c'est un système de construction qui peut générer des fichiers de projet et des fichiers de base de données séparément de la commande de construction.

Chaque fois que je vérifie une nouvelle branche avec des modifications majeures des fichiers, je dois exécuter Scons à partir de la ligne de commande pour régénérer mes fichiers vsproj, ce qui entraîne également une génération complète de toute façon. À Scons, d'après ce que j'ai vu, il n'y a aucune étape de génération de projet d'aucune sorte. C'est aussi pourquoi il ne prend pas en charge la génération de bases de données de compilation prêtes à l'emploi pour une utilisation dans clang-tools.

Actuellement, la seule solution viable pour coder Godot sur Windows (au niveau de l'IDE) est avec Visual Studio, sinon soyez prêt à utiliser simplement un éditeur de texte.

Scons est merveilleux et tout, mais quand j'ai un threadripper à 12 cœurs et 128 Go de RAM et que je dois attendre plus de 12 secondes sur Windows pour compiler un seul changement de ligne (la plupart du temps, c'est Scons qui pense), cela devient un peu ennuyeux.

Mais le véritable inconvénient de Scons (et cela pourrait être ma paresse dans la recherche) est que je ne peux pas compiler de fichiers cpp individuels. Être capable de compiler des fichiers cpp individuels sans construire l'ensemble du projet est un énorme booster de productivité et un vérificateur de santé mentale.

Ce ne sont pas seulement les changements de ligne qui prennent du temps, même déterminer s'il y a quelque chose à construire prend du temps...

Exécuter depuis 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 vous souhaitez créer un seul fichier cible, spécifiez-le sur la ligne de commande

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

Je voulais juste ajouter que la dernière version de CMake ajoute certaines des fonctionnalités manquantes mentionnées précédemment comme raisons de ne pas l'utiliser.
Compilations Unity : https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html
En-têtes précompilés : https://cmake.org/cmake/help/latest/command/target_precompile_headers.html

@Nosliwnayr Les deux sont pris en charge par des addons depuis de nombreuses années, ils sont bien testés et voulaient assez maintenant être inclus. Ce n'étaient jamais des raisons de ne pas utiliser CMake, car vous pouvez faire les deux dans CMake depuis très longtemps.

@bdbaddog
Je ne comprends pas, dois-je spécifier chaque fichier manuellement ? que fait ce truc .obj ?
comment l'appliquer à l'ensemble du projet ? recompile-t-il automatiquement les fichiers individuels ?

j'espère que les temps de compilation pourront être optimisés davantage, pouvoir compiler du code c++ presque instantanément sans astuces serait un dieu - après avoir vu à quelle vitesse godot compile, j'ai vraiment du mal à revenir au moteur irréel 4 (le compiler , m'a pris 45 minutes, mais maintenant le moteur est devenu plus gonflé, et cela prend jusqu'à 60 minutes, ce qui est fou)

Je veux dire, je pense que godot a le potentiel de compiler encore plus rapidement, et je remplacerais le système de construction moi-même, mais j'ai 0 expérience, donc je n'aurais littéralement aucune idée de ce qu'il faut faire

@Nosliwnayr
pouvons-nous s'il vous plaît éviter les en-têtes pré-compilés ? Je pense que ce sont des ordures complètes, restez simple

ils font aussi des projets de partage, beaucoup plus ennuyeux, et c'est juste un ballonnement sans fin, avec trop d'inconvénients dans mon esprit - mais bon, si quelqu'un les a utilisés efficacement, je suis cool, mais pour moi, ils semblent être un sale tour, à la place d'une véritable optimisation, et je n'aime pas les trucs bon marché pour être honnête

après avoir utilisé l'unreal engine 4, j'en ai marre des 20 Go de conneries pré-compilées, je ne pense pas qu'elles en valent la peine, il doit y avoir un système moins stupide (l'unreal engine 4, a pris jusqu'à 60 - 80 Go pour moi, pas cool)

si godot va dans cette direction, je suppose que les développeurs ont perdu la tête

putain, je préfère qu'ils s'en tiennent aux scons, si cela évite la boule de folie du moteur irréel 4, je pense que l'approche la plus intelligente serait d'améliorer les scons, au lieu de le remplacer carrément, par un tout nouveau cul cassé système de compilation, quand l'actuel fonctionne... plus ou moins

Je pense que l'effort mental requis pour s'introduire dans un tout nouveau système est bien plus élevé que le simple fait d'améliorer ce que nous avons déjà, et le nouveau compilateur pourrait finir par être fonctionnellement cassé pendant des mois

Je suis sûr que je ne vais pas me plaindre si cela se fait, mais avec un composant de moteur aussi critique, vous devez pratiquement tout faire, il n'y a pas de retour en arrière une fois que cela change

@RaTcHeT302 - La ligne de commande spécifiée est si vous vouliez compiler explicitement une seule cible (dans ce cas un fichier objet) (et bien sûr les fichiers dont il dépend)

En effet, si toutes les personnes qui se plaignaient de problèmes avec les SCons contribuaient à les résoudre plutôt que de suggérer de passer d'un système de construction compliqué à un autre plus récent et plus brillant... bon nombre de ces problèmes seraient résolus...

@bdbaddog Scons ne génère pas de fichiers de construction d'étape intermédiaire. Il effectue l'étape de "dépendance du projet" dans la même étape qu'il compile, et ils ne peuvent pas être séparés.

C'est comme dire à CMake de générer les fichiers du projet à chaque fois avant d'utiliser votre outil de construction, que ce soit MSVC, ninja-build, make, llvm, choisissez votre poison.

Si je change de branche git, je ne peux pas mettre à jour Visual Studio sans effectuer une génération de ligne de commande scons pour régénérer les fichiers .vsproj et .sln appropriés - et je nettoie presque toujours les modifications apportées à la branche de génération car j'ai rencontré des problèmes dans le passé.

Ces fichiers intermédiaires ne sont pas uniquement destinés à la construction, ils peuvent également être utilisés par des analyseurs statiques et d'autres projets.

Bien que je convienne que cmake n'est pas parfait (je ne l'aime pas autant moi-même) et que je préférerais la flexibilité de python, cmake a la meilleure intégration et la meilleure prise en charge de tous les outils de construction sur la table.

Lors de la conversion de mon fork en CMake, la plus grande partie de la complexité résidait dans les fichiers de génération de code. L'idée que la construction est compliquée est une erreur. La construction n'a pas besoin de scons parce que c'est complexe. C'est complexe parce qu'il utilise des scons.

Cela dit, la raison pour laquelle j'ai arrêté le travail est que j'ai rencontré les principaux développeurs de GDC en 2019 (à la rencontre GitHub) et ils ont dit qu'ils n'avaient absolument aucune intention de passer à quelque chose de plus utilisable, citant qu'ils préféreraient faire la construction entièrement sur Linux et en effet d'après ce que j'ai vu, ils violent le CLUF qu'Apple exige l'acceptation pour installer des outils de construction pour la compilation croisée.

La mentalité des responsables est vraiment "la fin justifie les moyens" et il ne semble pas y avoir de souci à traiter la construction comme un logiciel, et à la place, godot la traite comme une série de scripts qui produisent une construction.

Je ne contribuerai pas aux modifications que j'ai apportées à la génération de code à godot (bien qu'il soit plus lisible et plus rapide), et j'ai complètement abandonné ce moteur et j'ai continué ma vie. Je suis beaucoup plus heureux si je suis honnête. Le moteur a déjà une dette technologique considérable et je vois que ce sera un problème dans environ 3 ans, d'autant plus que le comité de normalisation C++ travaille sur un rapport technique sur l'outillage (je suis impliqué dans cela et j'ai fait pression pour que des choses comme les fichiers d'options soient standardisées dans une certaine mesure, mais ce n'est qu'un rapport technique, donc certaines personnes s'en écarteront).

C'est dommage aussi. Ma version CMake a pu détecter un tas d'erreurs d'analyse statique qui ont conduit à des tonnes de problèmes et sont facilement résolvables, mais je suis trop épuisé d'avoir discuté avec les développeurs à ce sujet à GDC pour signaler des bogues ou même tenter de les corriger eux. Mon énergie et ma santé mentale sont mieux dépensées ailleurs.

Il n'y a pas de monde où scons sera capable de gérer la conception des modules C++20 à venir, d'autant que j'ai crié comment cela casserait de nombreux outils. Il ne peut pas gérer le suivi des dépendances pour cela et nécessiterait une étape de pré-analyse, ce qui ralentirait encore plus le suivi des dépendances.

Enfin, je vais suggérer aux gens de ne pas essayer d'améliorer un outil qui ne peut accepter que des changements mineurs. Scons aurait besoin d'une réécriture complète à partir de zéro et d'un grand nombre de changements de rupture pour obtenir les améliorations que les gens recherchent ici.

Je suggère que ce problème soit clos car la discussion sur la modification du système de construction a trouvé une réponse à la GDC 2019, mais les responsables ne pensent même pas que cela vaut la peine de perdre leur temps à commenter ce problème, ce qui, je pense, montre à quel point ils se soucient de l'ergonomie. de développement.

J'ai l'impression que si le système de construction existant était converti à 100% de manière plug and play, les développeurs n'auraient aucune raison de ne pas changer.

Construire uniquement sur Linux est inutile. Avoir un moteur de jeu qui ne fonctionne pas sur Windows dissuadera les développeurs de jeux sérieux.

J'aimerais avoir l'impression que les développeurs du jeu se soucient suffisamment de changer le système de construction pour satisfaire ses utilisateurs.

L'une des raisons pour lesquelles j'ai quitté Unreal est que le moteur est conçu principalement pour la création de jeux Blueprint/front end. La création d'outils dans des modules c++ est extrêmement pénible et complexe dans Unreal.

Jusqu'à présent, à Godot, cela a été décemment agréable. Rendre les builds C++ plus rapides serait un gros plus pour la communauté.

IIRC utilise Wine pour exécuter les outils de construction MSVC. Cela ne change toujours pas votre point, et je suis d'accord.

Construire uniquement sur Linux est inutile. Avoir un moteur de jeu qui ne fonctionne pas sur Windows dissuadera les développeurs de jeux sérieux.

Godot a toujours été constructible sur de nombreuses plateformes, pas seulement sur Linux…

IIRC utilise Wine pour exécuter les outils de construction MSVC. Cela ne change toujours pas votre point, et je suis d'accord.

Les versions officielles de Windows sont compilées à l'aide de MinGW ; nous n'utilisons pas WINE pour exécuter MSVC sur Linux.

@marstaik - si vous changez de

alors essaie :

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

SCons devrait être capable de le faire sans faire une construction complète et il devrait également le faire correctement sans que vous ayez besoin de faire un nettoyage au préalable.
(BTW. Je suis le mainteneur du projet SCons)

@bdbaddog J'ai dû ajouter vsproj=True à cette commande, mais cela semble avoir fonctionné

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

Edit: Pour une raison quelconque, vous devez également ajouter l'indicateur -j ...

@bdbaddog J'ai dû ajouter vsproj=True à cette commande, mais cela semble avoir fonctionné

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

Edit: Pour une raison quelconque, vous devez également ajouter l'indicateur -j ...

Beaucoup de ces drapeaux ne sont pas des SCons vanilla, mais font partie de la façon dont divers packages (Godot dans ce cas) implémentent leur système de construction avec SCons.
Content que tu aies trouvé un moyen !

Pourquoi utiliser SConstruct et insister pour ne pas passer à un autre système de build ???

@tjysdsg La discussion ci-dessus résume très bien cela :slightly_smiliing_face:

Je vais fermer ceci parce que nous avons clairement indiqué au fil des ans que nous n'avions aucune intention a priori de changer le système de construction. Nous sommes satisfaits de SCons et chacun de ses défauts peut et doit être évalué individuellement, à la fois dans le cadre de notre propre utilisation de SCons et en amont si cela est dû à l'outillage lui-même.

Passer à un système de construction "plus cool" pour le plaisir ne se produira pas. La grande majorité des contributeurs principaux sont satisfaits d'utiliser SCons et c'est celui que nous connaissons le mieux maintenant. Le passage à un nouveau système de construction a à la fois un coût d'implémentation et un coût d'apprentissage, et il n'a pas été prouvé jusqu'à présent que cela en valait la peine.

Dans l'ensemble, un changement de buildsystem n'est pas quelque chose que nous accepterions de nouveaux contributeurs. Cela doit venir de l'intérieur, et tous les principaux contributeurs doivent le voir comme un changement positif pour qu'il ait un sens. Nous ne changerons pas le buildsystem juste pour plaire aux nouveaux utilisateurs qui tentent de construire Godot de source et d'une certaine manière ne aiment pas qu'ils doivent taper scons au lieu de cmake ou meson auquel ils sont habitués. Nous n'accepterons pas non plus les tentatives d'introduction d'un nouveau système de construction optionnel - par expérience, je sais que cela ne peut conduire qu'à des incohérences, des bogues et des différences de sortie.

Bien sûr, nous sommes ouverts à changer d'avis si des gains clairs peuvent être répertoriés (et montrés avec une preuve de concept fonctionnelle) qui dépassent les coûts de changement du système de construction, mais à partir d'aujourd'hui et après deux ans de discussion ici, je ne 't voir l'incitation.

@slurps-mad-rips l'a bien dit.

C'est complexe parce qu'il utilise des scons.

et

Ma version CMake a pu détecter un tas d'erreurs d'analyse statique qui ont conduit à des tonnes de problèmes et sont facilement résolvables

C'est carrément dégoûtant que CMake ne soit pas pris en compte sérieusement, je peux penser à de nombreuses raisons d'abandonner SCons, mais SPÉCIFIQUEMENT que CMake trouve des erreurs que Scons ne trouve pas, cela en vaut la peine d'utiliser autre chose.

Passer à un système de construction "plus cool" pour le plaisir ne se produira pas

CMake n'est pas "plus cool", c'est la norme. Si vous l'utilisiez réellement, vous comprendriez immédiatement pourquoi.

Bien sûr, nous sommes ouverts à changer d'avis si des gains clairs peuvent être répertoriés (et montrés avec une preuve de concept fonctionnelle) qui l'emportent sur les coûts de changement du système de construction

Je ne suis pas convaincu que quiconque soit ouvert à changer d'avis. Encore une fois, @slurps-mad-rips a montré des gains clairs, et elle a même fait tout le travail... C'est déjà fait.

Il est honteux, représentant la position officielle de l'équipe Godot, d'ignorer complètement ses efforts pour améliorer le processus de développement.

Je comprends tout à fait votre douleur mais je suis toujours d'accord avec les autres - toute la construction
les systèmes ont leur
avantages et inconvénients et généralement les mêmes. Il y a rarement une raison technique
pour le changer.
Quant aux raisons politiques, elles ne vous feront rien de bon à long terme
Cours. Tout le monde
préfère quelque chose de différent. De toute façon personne n'empêche personne de faire des fourchettes
pour quoi que ce soit
raisons, donc je suppose que celui-ci est aussi bon que n'importe quel autre.

Le vendredi 21 février 2020 à 13 h 38, dorkbox [email protected] a écrit :

@slurps-mad-rips https://github.com/slurps-mad-rips l'a bien dit.

C'est complexe parce qu'il utilise des scons.

et

Ma version CMake a pu détecter un tas d'erreurs d'analyse statique qui
ont conduit à des tonnes de problèmes et sont facilement résolvables

C'est carrément dégoûtant que CMake ne soit pas sérieusement pris en compte, je peux
pensez à de nombreuses raisons d'abandonner les SCons, mais SPÉCIFIQUEMENT que CMake trouve
Les erreurs que Scons ne trouve pas font qu'il vaut "la peine" d'utiliser autre chose.

Passer à un système de construction "plus cool" pour le plaisir ne se produira pas

CMake n'est pas "plus cool", c'est la norme. Si vous l'utilisiez réellement, vous le feriez
comprendre immédiatement pourquoi.

Bien sûr, nous sommes ouverts à changer d'avis si des gains clairs peuvent être répertoriés
(et montré avec une preuve de concept de travail) qui l'emportent sur les coûts de
changer le système de construction

Je ne suis pas convaincu que quiconque soit ouvert à changer d'avis. De nouveau,
@slurps-mad-rips https://github.com/slurps-mad-rips a montré des gains clairs,
et elle a même fait tout le travail... C'est déjà fait.

Il est honteux, représentant la position officielle de l'équipe Godot, de
ignorer complètement ses efforts pour améliorer le processus de développement.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/godotengine/godot/issues/16014?email_source=notifications&email_token=AAABPU2PBIEK6PFKQ2LDTHLRD6VKVA5CNFSM4ENJ6NN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LN54WWZH2247KTDN ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAABPU746R4YFHAI73Z57RTRD6VKVANCNFSM4ENJ6NNQ
.

@dorkbox - cmake a trouvé des erreurs d'analyse statique ? ou était-ce la sortie de la base de données de compilation de cmake exécutée via les outils d'analyse statique de llvm qui les a trouvées?

@bdbaddog , @slurps-mad-rips a fait le travail là-dessus, et il serait préférable de lui demander. (Je pense que ce serait le résultat de l'analyse statique de llvm, mais je ne suis pas celui qui a fait le travail de construction via cmake)

@slapin

Il y a rarement une raison technique pour le changer.

Qu'en est-il des outils d'analyse statique et de la prise en charge des fonctionnalités de langage moderne ?

@bdbaddog @dorkbox J'ai simplement activé clang-tidy pour rechercher des éléments tels que "retourner des références à des locaux non statiques" et "débordements de tampon" via CMake. J'ai également exécuté clang-check sur certaines choses et j'ai obtenu quelques résultats supplémentaires. J'ai également pu exécuter include-what-you-use , et il a trouvé pas mal d'inclusions d'en-tête inutiles.

Cela dit, je n'ai pas réellement "fini" le port cmake. La partie qui n'a jamais été portée était tout le travail que j'ai fait pour essayer de modifier les scripts python actuels qui appellent simplement f.write sur un fichier pour générer un fichier à partir de JSON. J'ai pu supprimer une grande partie de cette logique et la remplacer par un générateur de modèles générique basé sur jinja2. Cela a également résolu un hack que la version actuelle de scons fait sur Windows où elle lance un script en tant qu'exécutable.

Cependant, j'avais espéré conserver la parité avec la version scons et à tout le moins fusionner mes modifications de la génération de code. Cela ne s'est pas produit car les scripts python utilisés pour générer les fichiers source changent constamment et gardent ces modifications synchronisées avec ma modélisation jinja2 était un exercice de frustration.

Compte tenu du "non" très catégorique et dur que j'ai reçu des développeurs principaux lors de la rencontre GDC GitHub, j'ai décidé que je ne voulais plus contribuer à godot. Mes changements étaient indésirables, ne sont pas souhaités et ils sont indifférents à l'opinion de quiconque sur cette question. Je ne contribuerai pas à godot, ni à aucun fork de godot. Je vous souhaite bonne chance pour essayer de convaincre les principaux développeurs en la matière, mais c'est comme parler à un mur de briques. Inflexible, inébranlable et apathique au sort de tout le monde dans ce fil.

Donc, si SCons peut cracher la base de données de compilation qui est entrée dans les outils llvm, cela pourrait également être fait à partir de SCons.

Donc, si SCons peut cracher la base de données de compilation qui est entrée dans les outils llvm, cela pourrait également être fait à partir de SCons.

Il semble qu'il y ait le sophisme des coûts irrécupérables avec les SCons. Pourquoi ne pas utiliser quelque chose de plus simple, de rationalisé et qui fait déjà partie des outils de construction existants, comme cmake ?

Sur le site de scons :

Comparé aux scons, CMake est :

• Plus rapide
• Nécessite moins de code pour les tâches courantes
  
  
  
  • Sans doute plus stable
  
  
  • Prend en charge la sortie vers des projets tels que Code::Blocks, Xcode, etc. que scons ne fait pas
  
  

@dorkbox - Je suis le co-responsable du projet SCons. Je garde juste un œil sur la fonctionnalité souhaitée.

Les dernières versions et la prochaine ont eu des améliorations de performances.

De plus, nous avons des relations publiques pour la génération de fichiers ninja et certains membres de la communauté ont des outils de base de données de compilation. Ainsi, certains des problèmes seront probablement résolus (au moins partiellement, sinon entièrement) dans la prochaine version.

Je ne suis au courant d'aucun problème de stabilité affectant le projet godot que nous n'avons pas abordé. S'il y a des impayés, merci de nous le faire savoir.
(Contactez-nous via : https://scons.org/contact.html)

Je ne suis pas sûr que cmake nécessite vraiment moins de code pour les tâches courantes, je serais intéressé par une comparaison raisonnable.

Eh bien, ce qui m'amuse le plus avec les scons, c'est l'incapacité de générer du vieux
GNU make makefile. Manque de ninja - je peux vivre avec.
Gestion également des utilitaires de compilation croisée tels que les chaînes d'outils CMake et les outils automatiques
les capacités de compilation croisée sont un point faible de cmake.
Le reste est ok car je ne suis pas une personne IDE. Mon IDE est un environnement UNIX.

Le dimanche 23 février 2020 à 22:05 William Deegan [email protected]
a écrit:

@dorkbox https://github.com/dorkbox - Je suis le co-responsable du projet SCons.
Je garde juste un œil sur la fonctionnalité souhaitée.

Les dernières versions et la prochaine ont eu des performances
améliorations.

De plus, nous avons des relations publiques pour la génération de fichiers ninja et certaines communautés
les membres disposent d'outils de compilation de bases de données. Certains des problèmes sont donc probables
à traiter (au moins partiellement, sinon entièrement) dans la prochaine version.

Je ne suis au courant d'aucun problème de stabilité affectant le projet godot que nous
n'ont pas abordé. S'il y a des impayés, merci de nous le faire savoir.
(Contactez-nous via : https://scons.org/contact.html)

Je ne suis pas sûr que cmake nécessite vraiment moins de code pour les tâches courantes, je serais
intéressé par une comparaison raisonnable.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/godotengine/godot/issues/16014?email_source=notifications&email_token=AAABPU5TQQFET5RS2JDRY7TRELCHDA5CNFSM4ENJ6NN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LN5VMIXHJJKTDNGO ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAABPU6UHPX3HJTWPAFTPATRELCHDANCNFSM4ENJ6NNQ
.