Godot: Ziehen Sie in Betracht, das Buildsystem auf Meson oder ein anderes Buildsystem zu verschieben

Nach meinem Verständnis muss das Buildsystem-Tool Folgendes bereitstellen:

• Cross-Compilierung (von derselben Host-Plattform auf jede mögliche Zielplattform kompilieren).
  
  
  
  • Mit "möglich" meine ich, dass der Host dies zulässt (also sind macOS und iOS nur auf einem Mac-Rechner und unter Linux mit OSXCross möglich).
  
  
• Eine Möglichkeit zum Generieren von Dateien (Übersetzung aus PO, Shader-Klassen aus GLSL, Dokumentationsdaten aus XML).
  
  
  
  • SCons weiß, dass es sich bei den generierten Dateien um Abhängigkeiten handelt, sodass deren Änderung einen Neuaufbau relevanter Dateien auslöst. Auch dies sollte bedacht werden.
  
  
• Mehrere Ziele und Optionen innerhalb von Zielen (target=debug/release_debug/release, Architektur als x86 oder ARM, 32 oder 64 Bit).
• Optionen zum Anpassen der Build/Enable-Zusatzziele (gdnative Wrapper, kein Mono-Glue, Aktivieren/Deaktivieren von: Modulen, Treibern, veralteten Funktionen usw., Festlegen von Bibliotheken zur statischen Kompilierung mithilfe des integrierten Codes oder Verwendung der Systembibliotheken für jeden eine einzeln).

Ich kenne Meson nicht, aber wenn es alles oben bietet, sollte es in Ordnung sein (wenn ich nicht etwas vergessen habe). Natürlich muss jemand den quälenden Schmerz auf sich nehmen, das Buildsystem in Meson neu zu schreiben und dann zu zeigen, dass die Tooling- und Buildzeiten für Godot effektiv besser sind als für SCons.

Beachten Sie, dass für einige Abhängigkeiten von Drittanbietern ein Patch mit Godot kompiliert werden muss. Mir ist aufgefallen, dass Wrap Patch-Unterstützung bietet, aber es sieht so aus, als ob der Patch irgendwo zum Download verfügbar sein muss, während ich denke, dass es einfacher zu verwalten ist, wenn sie noch Teil des Repositorys sind. Außerdem erfordern einige von ihnen spezielle Kompilierungsflags, die nicht auf den gesamten Build angewendet werden sollten.

Ich denke, ein solcher Proof-of-Concept wäre sehr wertvoll, weil

• es gibt uns eine bessere Vorstellung davon, ob das neue Build-System alles, was wir brauchen, handhabt und wie gut es es tut
• es gibt uns konkrete statt abstrakte Daten zu diskutieren

Für den zweiten Punkt bedeutet dies, dass wir den Unterschied in der Build-Geschwindigkeit für Godot sehen können , wir können sehen, wie viel einfacher (oder komplexer) unsere Build-Skripte werden, und wir können die Unterschiede leichter vergleichen, um eine Wahl zu treffen, anstatt gebildet zu werden Vermutungen auf der Grundlage dessen, was es seiner Meinung nach bieten könnte.

--

Nun muss ich persönlich sagen, dass ich weder dafür noch dagegen bin, aber ich denke, es gibt mehr niedrig hängende Früchte zu jagen, anstatt (oder vorher?) das gesamte Build-System zu ändern. Vor allem zu diesem kritischen Zeitpunkt, wo so viele Hände wie möglich benötigt werden, um sicherzustellen, dass 3.0 und die ersten Patches in bester Form sind. Aber wenn wir das Build-System verbessern wollen, würde ich mir die CI-Build-Zeiten und den Aufwand der Mono-Build-Situation ansehen. (Ich denke, diese stehen auf Akiens TODO/Liste der Beschwerden?)

Auch die fehlerhaften parallelen Builds unter Windows sind scheiße, aber das ist mehr auf einer persönlichen Basis, die schön wäre, wenn sie behoben würde.

TL; DR:

• Ich stimme zu, dass die SCons-Dokumentation / -Ressourcen fehlt, die Build-Skripte sind einfach Python wirkt dem etwas entgegen, IMO
• Als neuer Mitwirkender war das Godot-Build-System eines der am wenigsten lästigen Setups, wirklich kurze Zeit bis zum ersten erfolgreichen Kompilieren
• Ich würde lieber den Aufwand sehen, der darauf verwendet wird, 3.0/3.1 so weit wie möglich zu verbessern, und vielleicht darüber nachdenken, sobald diese stabil sind
• Bessere CI-Build-Zeiten und einfachere Mono-Builds könnten wichtiger sein

Meine Meinungen. :)

Ich glaube absolut, dass die Einführung von 3.0 und die Konzentration auf die folgenden Releases (3.0.1, 3.1) Vorrang vor diesem Thema haben sollten, um es festzuhalten.
Ich weiß , warum die Menschen nicht wie an der Arbeit auf buildsystems (da es wirklich nur zum Nutzen anderer Entwickler / besonders technisch versierten Endanwender - die nicht un wichtig ist, dann ist es sinnvoll , die Devs' und Mitwirkenden des Leben leichter zu machen , aber letztendlich ist das Glück der Endbenutzer das Ziel) und es gibt diese ganze Sache mit den "Gelegenheitskosten", dh. wenn die für die Verbesserung des Build-Systems aufgewendete (oder verlorene/verschwendete, je nachdem, wen Sie fragen) für die Verbesserung des Projekts selbst verwendet werden könnte. (Es sei denn, Sie sind wie ich und können sowieso nicht wirklich an der C++-Seite arbeiten.)

Und letztendlich funktionieren SCons wirklich "einfach", was für die meisten Entwickler da draußen wahrscheinlich gut genug sein wird. wenn es überhaupt genug Unterstützung erhält, um am Ende tatsächlich bearbeitet zu werden.

All dies sagte, ich könnte den POC später in dieser Woche in meinem Fork starten, für diejenigen, die bereit sind, den Fortschritt dabei zu verfolgen (und mir wahrscheinlich helfen, da ich nicht viel Erfahrung mit dem Schreiben von Build-Systemen habe). aber ich werde höchstwahrscheinlich für eine Weile keinen Pull-Request dafür öffnen.

Ich finde SCons nicht wirklich langsam, und seine Flexibilität (von der wir viel profitieren) ist wahrscheinlich von nichts anderem übertroffen. SCons ist auch extrem bewährt, ich finde, dass es nie einen Build vermasselt.

Ehrlich gesagt, es sei denn, jemand meldet sich freiwillig, das gesamte Build-System neu zu schreiben (nicht nur ein Proof of Concept) und zeigt, dass es entweder einfacher (viel weniger Code) oder viel schneller ist , ich würde nicht einmal etwas anderes in Betracht ziehen, nicht einmal ein bisschen.

Nun muss ich persönlich sagen, dass ich weder dafür noch dagegen bin, aber ich denke, es gibt mehr niedrig hängende Früchte zu jagen, anstatt (oder vorher?) das gesamte Build-System zu ändern.

Das ist für diese Änderung nicht wirklich schädlich. Ich meine, die meisten Godot-Mitarbeiter arbeiten in ihrer Freizeit und arbeiten an dem, was sie wollen. Für den Fall von @NullConstant scheint es entweder " willst , nur dass es schwieriger ist, mit der tatsächlichen C++-Codebasis und Fehlersuche an etwas Unbekanntem zu arbeiten), also dies zu tun ist im Allgemeinen eine gute Sache.

Außerdem ist das Argument "es gibt bessere Dinge zu tun" der Weg, um IMO nichts tun zu lassen. Natürlich wird nichts zusammengeführt, bis wir sicher sind, dass es nicht kaputt geht und nicht kurz vor einer Veröffentlichung gemacht wird. Ich stimme zu, dass es wichtigere Dinge gibt, aber das bedeutet nicht, dass dies nicht gestartet werden kann.

Die Sache ist, dass jemand, der daran arbeitet, dies wahrscheinlich alleine tun muss. Natürlich können spezifische Fragen von den Kernentwicklern beantwortet werden, aber mehr wird nicht passieren. Deshalb galt SCons auch nie als abgelöst: Niemand wollte sich bisher die Hände schmutzig machen. Wie ich schon zu Bullet sagte: Jemand muss es zum Laufen bringen und beweisen, dass es möglich und besser ist, sonst bleiben wir beim Status Quo.

Ich denke aber, SCons ist langsam. Nicht viel langsam, aber Dinge wie der Fortschrittsstatus und der Cache machen es langsamer für Neuaufbauten (die Verwendung von Festplatten-E/A zum Lesen aus dem Cache macht es langsam), also deaktiviere ich diese beim Neuaufbau. Es dauert ein bisschen, bis man mit der Arbeit beginnt, danach geht es ziemlich schnell.

Ich weiß nicht, ob Meson wesentlich schneller sein wird, aber wenn jemand bereit ist, es zu versuchen, bin ich nicht dagegen.

Oh sicher, wenn sich jemand die Zeit nimmt und zeigt, dass es eine Verbesserung ist, die groß genug ist, um einen Wechsel zu rechtfertigen, bin ich dafür :)

Wie ich schon sagte, bin ich nicht wirklich in der Lage, C++-Bugs zu jagen oder neue Funktionen an dieser Front hinzuzufügen, also bin ich damit einverstanden, dies stattdessen zu tun.

Ich nehme an, dass dies mir (und / oder jedem anderen, der in Zukunft daran arbeitet) ein ziemlich sauberes, zweifaches Ziel gibt, das ich erreichen kann:

• Bring Godot dazu, mit Meson in irgendeiner Form zu kompilieren, um damit zu beginnen
• machen es so einfach wie SCons im Moment ist, möglicherweise sogar noch mehr (durch Verbesserung der Geschwindigkeiten)

Und ich vermute, dass die Geschwindigkeit von SCons nicht schrecklich-schrecklich ist (der Großteil der Zeit des Build-Prozesses entfällt sowieso auf das eigentliche Verlinken und Kompilieren, daher ist die Verlangsamung durch den Overhead des Build-Systems wahrscheinlich etwas zu vernachlässigen), aber es ist sicherlich verbessert werden könnte, und Meson als Alternative anzubieten, könnte genau diese Verbesserung sein. Wir werden sehen.

Das größte Problem besteht wahrscheinlich darin, die Python-Build-Skripte für die automatische Generierung von Code wie die Shader zu ersetzen, es scheint nicht so, als hätte Meson eine solche Funktion.

und Meson als Alternative anzubieten, könnte genau diese Verbesserung sein. Wir werden sehen.

Es sollte keine Alternative sein, entweder gehen wir dazu, wenn es eindeutig besser ist, oder wir bieten es nicht einmal an. Es ist verrückt, zwei Build-Systeme unterstützen zu müssen.

Stimmt, das ist gerecht.

Ich werde in den nächsten Tagen/Wochen anfangen, daran herumzuhacken, um zu sehen, ob das irgendwohin führt und ob es sich wirklich lohnt, es weiterzuverfolgen (auch wenn ich die ganze Zeit die einzige Person bin, die daran arbeitet).

Ich melde mich, wenn ich etwas Vorzeigbares (wie einen Benchmark) bekomme.

Obwohl, nicht meson, werde ich in den kommenden Wochen einen Test machen, um zu sehen, was es braucht, um Godot unter Bazel für Windows 64 Bit unter msvc zu erstellen.

Bazel ist ein weiteres System, dessen Vorteil eine kürzere Build-Beschreibung und schnellere Builds sind. Außerdem wird es von Google gepflegt, so dass es nirgendwo hinführt.

Wie auch immer, ich kann das nicht überprüfen, aber es ist sehr wahrscheinlich, dass 99% der Rechenzeit, die zum Erstellen von Godot aufgewendet wird, im Compiler aufgewendet wird. Selbst wenn kein Overhead für die Bausoftware erforderlich wäre, würde dies zu einer Verkürzung der Bauzeit um 1 % führen. Selbst eine Verringerung um 5% wäre nicht wert, es sei denn, sie erlaubt weniger Code und mehr Zuverlässigkeit (oder wenn ich mich irre :) ).

Für die rohe Build-Geschwindigkeit eines sauberen Klons bezweifle ich, dass es einen signifikanten Unterschied geben wird. Aber es kann von Bedeutung sein, wenn Sie die Wiederherstellungsgeschwindigkeiten berücksichtigen. SCons baut immer viele Sachen neu auf, die nicht geändert wurden, wenn ich einen neuen Commit ziehe (insbesondere OpenSSL und Bullet, die beide große Bibliotheken sind und eine Weile brauchen, um sie zu erstellen).

Wie ich bereits sagte, startet SCons langsam (dauert ein paar Sekunden, bevor die Kompilierung wirklich beginnt). Wenn Sie den gesamten Quellcode erstellen, der vernachlässigbar ist, aber nur eine Zeile geändert und zum Testen kompiliert wird, kann dies den Workflow erheblich verbessern (was IMO im Buildsystem am wichtigsten ist: den Leuten helfen, die mit dem Code arbeiten) . Eine Verringerung von 5s in einem 10-Minuten-Build ist also irrelevant, aber eine Verringerung von 5s in einem 10s-Rebuild ist eine große Verbesserung.

Aber ich stimme zu, dass jede Änderung in dieser Hinsicht viel getestet werden sollte, um zu beweisen, dass sie funktioniert. Wie @reduz feststellte, haben SCons nie einen Build durcheinander gebracht, und das ist zu berücksichtigen.

Bazel ist ein weiteres System, dessen Vorteil eine kürzere Build-Beschreibung und schnellere Builds sind. Außerdem wird es von Google gepflegt, so dass es nirgendwo hinführt.

Es gibt sogar eine wachsende Wikipedia-Kategorie von "Dingen, die Google eingestellt hat". :)

@mhilbrunner Nö es wird noch gepflegt https://github.com/bazelbuild/bazel

Ihr Punkt war, dass es nicht bedeutet, dass es für lange Zeit existieren wird, nur weil Google es geschafft hat.

Da wir C# für die Spieleentwicklung angenommen haben, könnten wir genauso gut etwas wie Cake ausprobieren. Ich habe es selbst aber noch nicht ausprobiert, daher interessiert mich, was Sie dazu sagen. Zumindest zum einen würden Skripte schneller laufen als mit Python.

Da wir C# für die Spieleentwicklung angenommen haben, könnten wir genauso gut etwas wie Cake ausprobieren.

Ich bin mir nicht sicher, ob eine Mono-Installation zum Kompilieren von Godot eine gute Idee ist, wenn man bedenkt, dass Godot hauptsächlich ein C++-Projekt ist und ohne C#-Unterstützung kompiliert werden kann.

Das Leistungsniveau von Meson oder CMake (mit dem Ninja-Generator) sollte für Godots Zwecke mehr als ausreichend sein.

@Calinou Sie haben wahrscheinlich Recht, obwohl es so aussieht, als ob jeder auf den C#

Bearbeiten:

Zur Verdeutlichung klingt es für mich nicht so schlimm, dass das Mono Framework installiert sein muss, um Godot zu bauen, da die sogenannten AAA-Game-Engines viel mehr Speicherplatz benötigen:

• Godot <50MB
• Godot mit Mono-Unterstützung (<50MB) + Mono Framework (~350MB) = ~400MB
• Unwirklich ~20GB
• Einheit ~10GB
• CryEngine ~8GB

Außerdem könnten wir die Mono-Unterstützung standardmäßig im Editor hartcodieren und eine Logik haben, um zu erkennen, ob C#-Skripting zur Laufzeit unterstützt wird oder nicht, und nach dem Mono-Framework oder den entsprechenden Exportvorlagen fragen.

Ich liebe CMake und Meson sieht cool aus, aber ich neige dazu, diesem Artikel zuzustimmen: http://www.rojtberg.net/1481/do-not-use-meson.

Ich bin sehr daran interessiert, die Beinarbeit zu leisten, um Godot nach Meson zu bringen. Das einzige, was mich derzeit davon abhält, zu Godot beizutragen (und es zu verwenden), ist Scons. Ich musste es vor Jahren benutzen, und ich habe in meinem ganzen Leben noch nie eine schmerzhaftere Erfahrung mit inkrementeller Entwicklung gemacht.

Der oben verlinkte Artikel enthält viele Strohmann-Argumente, die argumentieren, dass CMake bereits existiert und wir das einfach verwenden sollten. Die Build-Dateien von Meson sind extrem einfach zu lesen und verwenden eine Syntax, die der von Python nahe kommt. Die Konvertierung kann schnell gehen. Was ich in diesem Thread poste, ist, wenn die Beinarbeit erledigt wäre, würde ein Pull-Request überhaupt für das Zusammenführen in Betracht gezogen?

Was ich in diesem Thread poste, ist, wenn die Beinarbeit erledigt wäre, würde ein Pull-Request überhaupt für das Zusammenführen in Betracht gezogen?

Es wird in Erwägung gezogen, muss sich aber gegenüber SCons als vorteilhaft erweisen.

Wenn Sie CMake nur für ein weiteres Build-System und nicht für den De-facto-Standard halten, haben Sie am Ende zu viele Optionen. Warum Meson über SCons? Oder sind Bazel/Buck auch anständige Werkzeuge? Aber das größte Argument, das ich für CMake habe, sind die Tools, die zur Unterstützung dieses Ökosystems entwickelt wurden. Clang-Kompilierungsdatenbanken, Unterstützung für das Packen auf mehrere Betriebssysteme usw. Die einzigen gültigen Nachteile, die ich gehört habe, sind schlechte Syntax und Dokumentation, aber das ist nicht wirklich stark genug, um meine Position zu ändern.

Warum Meson über SCons?

Meson generiert Ninja-Dateien, was für die inkrementelle Entwicklung viel schneller ist. Zusätzlich auf Windows, müssen Sie nicht jede Art von Visual Studio Weg Manipulation zu tun. Meson funktioniert out-of-the-box. Die Verwendung von Meson über Scons würde den Aufwand für das Targeting von Fenstern erheblich reduzieren, insbesondere für diejenigen, die Visual Studio verwenden möchten (wobei Meson wie CMake Projekte generieren kann).

Oder sind Bazel/Buck auch anständige Werkzeuge?

Angesichts der Tatsache, dass Bazel und Buck beide in Java geschrieben sind (eine Abhängigkeit von Godot nur, wenn Sie auf Android abzielen, und selbst dann könnte man technisch nur das NDK verwenden), würde ich argumentieren, dass sie als primäre Abhängigkeit für alle gelten Benutzer. Python ist bereits in der Abhängigkeitsliste enthalten, und Sie können Meson (und Ninja) einfach über ein schnelles pip install meson installieren

Clang-Kompilierungsdatenbanken

Meson unterstützt dies standardmäßig, da dies eine in Ninja integrierte Standardfunktion ist

Unterstützung für das Packen auf mehrere Betriebssysteme

Meson unterstützt dies ebenfalls und verlässt sich gegebenenfalls stark auf pkg-config

Die einzigen gültigen Nachteile, die ich gehört habe, sind schlechte Syntax und Dokumentation

Meson hat eine sehr Python-ähnliche Syntax, die auf Variablen, Objekten und eingebauten Funktionen beruht. Meiner Meinung nach schreiben

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

vs

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

ist viel einfacher, insbesondere angesichts der Tatsache, dass cmake manchmal zwischen Groß- und Kleinschreibung unterscheidet und manchmal nicht. Wenn Sie anfangen, sich mit Generatorausdrücken zu beschäftigen, kann es extrem haarig werden.

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

Das entsprechende Meson sieht so aus:

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)

Ich denke, ich sollte übrigens anmerken, dass Meson von allen C++-Buildsystemen da draußen das am wenigsten schreckliche ist . Argumente gegen seine Verwendung sind in der Regel ein Bild eines Web-Comics, einige Handbewegungen darüber, wie CMake am häufigsten verwendet wird, also sollten Sie sich einfach damit auseinandersetzen und "Hey, zumindest ist CMake keine Autotools".

Aber vor allem (und ich denke, das ist eine wirklich wichtige Sache, besonders für diejenigen, die Godot wie für gdnative verwenden) unterstützt Meson nativ vorkompilierte Header. CMake tut dies nicht (und die Verwendung von Cotire zum Hacken des Builds kann mehr Probleme verursachen, als es wert ist).

Ich kann Ihnen nicht sagen, wie sehr dies den Build für gdnative-Benutzer beschleunigen könnte, aber es wird einen erheblichen Schub für gcc und msvc bedeuten (zumindest ist eine Leistungssteigerung bei msvc unvermeidlich). Fügen Sie die Verwendung von extern template für die sehr kleinen Mengen an Vorlagencode hinzu, die in Godot zu finden sind, und Sie könnten anständige Verbesserungen der Buildzeit feststellen, die für iterative und inkrementelle Builds wichtig sind.

Meson generiert Ninja-Dateien, was für die inkrementelle Entwicklung viel schneller ist.

Beachten Sie, dass CMake anstelle herkömmlicher Makefiles auch Ninja-Build-Dateien generieren kann. Dies geschieht, indem -G Ninja an die Befehlszeile übergeben wird. Es funktioniert bei den meisten Projekten, die ich ausprobiert habe, recht gut und ist insgesamt etwas schneller (und standardmäßig werden alle CPU-Threads verwendet).

Meson gewinnt immer noch in den Rohleistungsvergleichen, die ich gesehen habe, aber dies hilft definitiv, die Lücke zwischen Meson- und CMake-Leistung zu schließen.

Ja, CMake installiert Ninja jedoch nicht automatisch für Sie und ist nicht der Standardgenerator. Meiner Erfahrung nach wird die meiste Zeit von CMake damit verbracht, das Projekt zu konfigurieren.

OK, das ist ziemlich gründlich! Ich freue mich, dass Sie eine gute Vorstellung davon haben, welche Funktionen Sie in einem Build-System schätzen. Ich denke immer noch, dass es in der C++-Welt ein Standard-Build-System geben sollte, auf das sich Projekte verlassen können. Ich wünschte nur, Meson wäre ein CMake-Transpiler im Gegensatz zu seinem eigenen Ding.

Ich denke immer noch, dass es in der C++-Welt ein Standard-Build-System geben sollte, auf das sich Projekte verlassen können.

Vertrauen Sie mir, niemand will das mehr als ich. Ich bin zu einer Art Müllgoblin für Build-Systeme geworden und habe sogar auf der CppCon einen Vortrag darüber gehalten. Leider (oder zum Glück?) interessiere ich mich sehr für Build-Systeme, fast bis zur Besessenheit. :)

Ich möchte dies nur sagen, aber jedes Mal, wenn ich Godot unter Windows lange erstellt habe, habe ich festgestellt, dass Python ständig > 15% meiner CPU beansprucht. Ich bezweifle, dass es nur langsam anfängt.

Wer wird einen kleinen Godot-Prototyp bauen, der mit Meson gebaut wurde? Ich bin nie dazu gekommen, einen kleinen Test für Bazel zu erstellen.

Ein nur 2D-Build von Godot sollte ausreichen, um mit allen deaktivierten Optionen zu testen.

Die erste Straßensperre, mit der ich konfrontiert war, war core/make_binders.py. Dies ist der automatisch generierte Code, den Godot verwendet.

Ich habe einen ersten Prototyp im Build-System Bazel erstellt, aber ich werde das Setup zu einem anderen Thema besprechen. https://github.com/godotengine/godot/issues/18518

Sie haben unter der Woche keine Zeit, aber andere können das Bazel BUILD erweitern.

Lol, wie kam Bazel dazu?

Da es möglicherweise eine einmalige Gelegenheit gibt, zu einem anderen Build-System zu wechseln, sollten wir nicht nach den bestmöglichen Optionen suchen? Ich für meinen Teil wäre daran interessiert, eine Vergleichstabelle von Cake vs Bazel vs Scons zu sehen, obwohl ich zugeben muss, dass ich keine Erfahrung mit Cake habe, um die Beinarbeit für diese Tests zu erledigen.

@rraallvv meinst du Kuchen oder CMake?

@isaachier Mein Fehler , ich habe über

Ist das nicht nur für C#?

@isaachier Ich weiß es wirklich nicht, die ganze Zeit ging ich davon aus, dass Cake dazu in der Lage ist, genau wie SCons in Python geschrieben werden und C++ unterstützen. Trotzdem habe ich gerade bei ihrem gitterchat nachgefragt, ich werde die Antwort hier nochmal posten.

@rraallvv fürs Protokoll Ich denke, die Idee eines 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.

Meine persönliche Meinung:

• CMake : Ziemlich hässliche Sprache, aber allgegenwärtig und praktisch der Industriestandard.
• SCons : Langsam, alt und IDK-Status. Verwendet Python.
• meson : Neues, cooles, Python-basiertes Build-System, das nicht unglaublich langsam ist. Hauptnachteil ist die Flugbahn. Unklar, ob dies nur eine weitere Variante des Build-Systems der Woche sein wird.
• Autotools : Uralt, keine Tooling-Unterstützung (dh Kompilierungsdatenbanken für Clang-Autocomplete-Unterstützung oder statische Analyse). Keine Windows-Unterstützung. Um jeden Preis vermeiden.
• bazel : Ein Google-Paket-Manager/Build-System in einem. Fügt mit einem Plugin wie Hunter nicht viel über CMake hinzu. Außerdem tendiert Google-Software dazu, sich auf das zu konzentrieren, was Google braucht, und nicht auf die breite Öffentlichkeit. Zu neu, um die langfristige Flugbahn abzuschätzen.

Ich versuche, CMake zu pushen, wann immer ich die Gelegenheit dazu habe, weil ich einen De-facto-Standard für C++ haben möchte und CMake derzeit den größten "Marktanteil" hat.

@isaachier Vielen Dank für das Teilen dieser Informationen, ich dieses C++ REPL könnte für ein Build-System verwendet werden, wenn man auf die nächste Ebene gehen und die Debatte darüber beenden möchte, welches besser, schneller usw. ist.

Ich verstehe nicht. C++ wäre wahrscheinlich eine schreckliche Build-Sprache. Langsamkeit hat mehr mit dem internen Build-System-Kern AFAIK zu tun, nicht mit den Details der verwendeten Skriptsprache.

@isaachier Ich vermute, dass SCons so langsam ist, weil es in Python geschrieben wurde, aber wenn jemand die Aufgabe übernehmen würde, das gesamte Build-System auf C++ zu portieren und es auch dazu zu bringen, C++-Skripte JIT zu kompilieren, um diese Builds auszuführen, wäre das viel Schneller. Vielleicht könnte das gleiche für jedes Build-System da draußen gelten.

Es ist eine nette Idee, aber Meson wird von den meisten Accounts nicht als langsam angesehen, aber es ist in Python geschrieben.

Ich bezweifle, dass Meson ein Geschmack der Woche sein wird, da das GNOME-Projekt derzeit Autotools zugunsten von Meson aufgibt.

Außerdem ist Scons langsam, nicht weil es in Python geschrieben ist, sondern weil es auch den Build ausführt. Es ist ein direktes Build-System, wie make oder ninja, verwendet aber auch riesige Mengen an XML für Definitionen und ein großer Teil seines Codes besteht eigentlich nur aus XSLT-Konvertierungen.

Meson hingegen führt seine Build-Skripte aus, um einen Abhängigkeitsbaum zu generieren, und gibt diesen dann in eine Ninja-Datei aus. Meson ist schnell, weil Ninja schnell ist. Außerdem ist in Meson nicht alles ein String, wie in CMake.

Zu guter Letzt sollte ich anmerken, dass es in der Entwicklung mehrere Build-Systeme gibt, in denen Sie in C++ Skripte schreiben können (ich schreibe tatsächlich eines davon). Godot bittet jedoch, zu einem Build-System zu wechseln, das noch nicht existiert ( und schlimmer noch, dass ich selbst schreibe) ist meiner nicht so bescheidenen Meinung nach etwas arrogant ;)

Ich möchte auch wiederholen, dass Python unter dem aktuellen Entwicklungsworkflow eine Notwendigkeit ist. Das ist auch Meson. Und das macht den Wechsel zu Meson so einfach wie einen Aufruf des pip Tools von Python.

Ich stimme @reduz voll und ganz zu, dass ich SCons auch nicht wirklich langsam finde.

Wie @slurps-mad-rips sagte:

Scons ist nicht langsam, weil es in Python geschrieben ist, sondern weil es auch den Build ausführt

Mann scons:

scons unterstützt das parallele Erstellen mehrerer Ziele über eine Option -j, die als Argument die Anzahl der gleichzeitigen Aufgaben übernimmt, die gestartet werden können:
scons -j 4

Ich habe eine CPU mit 8c16t, daher ist die Verwendung von "scons p=x11 -j 18" für mich sehr schnell.
Es ist 10x schneller als "scons p=x11" als Standardeinstellung "-j 1" zu verwenden.
Hat jemand eine Single-Core-CPU im Jahr 2018?
Lassen Sie Ihre CPU voll arbeiten.
bitte versuchen Sie es.

Nicht jeder hat diese großen CPUs, aber was noch wichtiger ist, Meson (naja, Ninja) ist bei inkrementellen Neukompilierungen viel schneller. Scons führt standardmäßig eine MD5-Hash-Summe durch, um zu sehen, ob sich eine Datei geändert hat. Godot verwendet die MD5-Timestamp-Einstellung, was bedeutet, dass eine Datei nur dann gehasht wird, wenn sich ein Timestamp geändert hat. Es ist immer noch lächerlich.

Ich denke, der beste Weg, um zu beweisen, was besser ist, ist, einen neuen zu schreiben und zu sehen :)

Scons ist für viele Leute nicht schnell, insbesondere für Windows-Benutzer, die Probleme mit etwas über -j 1 haben.

@slurps-mad-rips es hängt vom Projekt ab. Ninja scheint seine Geschwindigkeit ein wenig zu sehr zu übertreiben. Siehe diesen Artikel: http://david.rothlis.net/ninja-benchmark/. Es scheint, dass das Zählen von Quelldateien hier die beste Wahl ist. Wenn <20K macht keinen großen Unterschied.

@isaachier dieser Benchmark liegt zwischen Make und Ninja, nicht Ninja und Scons, also musst du mir verzeihen, wenn ich nicht darauf achten möchte. ;)

Ich denke, der beste Weg, um zu beweisen, was besser ist, ist, ein neues zu schreiben und zu sehen :)

Ich stimme zu, es hat keinen Sinn, Fahrräder abzuwerfen. Wenn Sie eine Meinung zu einem besseren Build-System haben, implementieren Sie es und beweisen Sie, dass es besser ist. Ansonsten ist dies eine Meinungsdiskussion und führt nirgendwo hin. @fire hat bereits einen Teiltest mit Bazel durchgeführt: https://github.com/godotengine/godot/issues/18518.

@slurps-mad-rips ya ganz anderes Thema, nicht SCons. Ich meinte nur Make vs. Ninja ist kein verrückter Unterschied.

Kleines Update: Ich gebe den Versuch auf, zu Meson zu wechseln. Es war stückchenweise und obwohl die Build-Dateien etwas einfacher zu lesen sind, verbringe ich den größten Teil meiner (jetzt seltenen und knappen) Freizeit damit, mit dem aktuellen System auf dem Laufenden zu bleiben, anstatt Scons in Meson zu verschieben.

Im Moment werden viele Codes und Operationen direkt in den scons-Skripten platziert, was den Wechsel zu einem anderen Build-System erschwert. Ich würde argumentieren, dass Zeit damit verbracht werden sollte, die vorhandenen Python-Skripte zu entkoppeln, die Code von Scons generieren, da dies den Wechsel zu einem anderen Build-System wie Meson, Cmake oder sogar Bazel viel einfacher machen würde.

Gut, dass ein Patch gerade zusammengeführt wurde, um die gesamte Codegenerierung zu verschieben. https://github.com/godotengine/godot/pull/17595 Nicht aufgeben!

SCons Projekt-Co-Manager hier. Ein paar Anmerkungen:
1 - SCons befindet sich in aktiver Entwicklung und seit unserer Migration zu Github sehen wir eine erhöhte Rate an Pull-Requests.
2 - Wir haben einige spezifische Teile von SCons identifiziert, die für etwa 50 % der inkrementellen Build-Zeit von Null verantwortlich sind, und arbeiten aktiv daran, dies zu beheben. (Die Subst-Funktionalität)
3 - Wir haben begonnen, Python 3.5+ (sowie 2.7.x) mit SCons 3.0 zu unterstützen
4 - Lassen Sie mich vorschlagen, dass es eine effektivere Nutzung der Entwicklerzeit sein könnte, anstatt zu versuchen, auf N verschiedene Build-Systeme zu portieren, etwas Zeit beizutragen, um SCons zu verbessern
5 - Wir haben einige der niedrig hängenden Früchte der Leistungssteigerung identifiziert und behoben, die in 3.0.0 und 3.0.1 veröffentlicht wurden. Wenn Sie eine frühere Version verwenden, kann der inkrementelle Null-Build 5-15% langsamer sein. (unter der Annahme von Python 2.7.x)

Wie immer ist das SCons-Projekt bereit und bereit, Projekten, die SCons verwenden, bei Problemen zu helfen, auf die sie stoßen.

Einige "Statistiken" für SCons & Godot.

Ich benutzte (und tue es immer noch) einen Q6600, der eine 4-Kern-CPU von 2008 oder so mit 2,4 GHz (und einer geringeren Anzahl von Anweisungen pro Zyklus) ist als die Prozessoren, die wir heute "alle" verwenden (i7s).

Auf Q6600 dauerte ein Build zwischen 3 und 5 Minuten (oder mehr, aber die genaue Anzahl ist nicht so wichtig), von denen ~35-40 Sekunden von SCons damit verbracht wurden, den Baum der Abhängigkeiten und so weiter zu analysieren (die Vorbereitungsarbeit) ... also 80 % der Zeit damit verbracht, den Prozess cl.exe (MSVC-Compiler) immer wieder auszuführen.

Also in Bezug auf Leistung und Optimierung, es sei denn, SCons (wirklich Python, nicht SCons) haben ein schreckliches Prozessaufrufsystem, das mehr Zeit in Anspruch nimmt, als es sollte, oder einige andere Tools kompilieren nicht eine Datei pro Prozess (wie SCons derzeit) und die 1 Der Overhead für den Prozess pro Datei ist erheblich (ich bin kein Experte für cl.exe-Komplizierungsinterna und Start-Overheads), die einzige Leistungsoptimierung, die ein schnelleres Build-System erzeugen würde, liegt wahrscheinlich in der Erstellung der Abhängigkeitsbaumphase und anderen Vorbereitungen für die Komplikation .

Also optimieren wir diese 35-40 Sekunden aus einem 5-Minuten-Build (auf i7s optimieren wir jetzt wahrscheinlich einen 20-Sekunden- Einzelkern- Setup-Schritt aus einem 3-Minuten- Multi-Core- Build).

Also, um es zusammenzufassen, wenn ich mich richtig erinnere, sind 3 bis 5 Minuten tatsächlich ein 4-Kern- Multicore- Build, während ein Single-Core-Build etwa 10 dauert? Ich muss meine Tests wiederholen...

SCons zu "optimieren" bedeutet also, die ersten 35 Sekunden des Build-Starts mehr oder weniger zu optimieren ...

Soweit die "Optimierungen", wenn es um SCons im Vergleich zu anderen schnelleren Build-Systemen geht... Es ist möglich, dass die eigentliche Kompilierung ein wenig optimiert wird, indem vermieden wird, eine einzelne cl.exe für jede obj-Datei aufzurufen, aber das ist nur, wenn der Prozess-Overhead ist erheblich (ich fürchte, HDD wird dort immer der eigentliche IO-Engpass sein (und nicht die CPU), was ohne SSD nicht vermeidbar/milderbar ist)

Alle diese obigen Absätze betrachten einen "vollständigen Build". Das heißt, SCons "betrügen", wenn alles bereits erstellt ist und seine hartnäckigen Konsistenzprüfungen besteht. Wenn Sie also eine einzelne Datei ändern, wird es tatsächlich eine "einzelne Datei" kompilieren und dann alles wieder einbinden, wodurch ein "vollständiger Build" zu etwas wird eines inkrementellen Builds). Dies erfordert jedoch diese 35-40 Sekunden der vollständigen Vorberechnung des Abhängigkeitsbaums ...

Also, ein "inkrementeller Build" dauert auf meinem alten Computer ungefähr 45 Sekunden, und ich dachte, als ich vor 2 Jahren ein Neuling war, dass es CPU-gebunden sein würde, aber tatsächlich könnte es IO-gebunden sein (überprüfe mehrere tausend Dateien auf der Festplatte ) für einen vollständigen Abhängigkeits-Sweep/Baum-Neuaufbau ... Wenn es also IO-gebunden ist, wird kein "schnelleres Buildlsystem" das lösen ...

Meine hackige Idee von vor 2 Jahren war zu versuchen, einen Dateisystem-"Watcher" an SCons anzuhängen, SCons laufen zu lassen und eine einzelne geänderte Datei neu zu kompilieren (und ihre Abhängigkeiten, das ist automatisch), und dann einfach alles wieder zurückverknüpfen zu lassen ... Obwohl mir heute klar ist, dass das Verlinken wahrscheinlich immer noch einen vollständigen Abhängigkeits-Sweep ausführen würde ... das heißt, der Suchlauf / Neuaufbau des Abhängigkeitsbaums kann mit einer Option beendet werden und SCons verwenden dann seinen zwischengespeicherten Dep-Tree ... was etwa 15-20 spart Sekunden des 35-sekündigen Vorberechnungsschritts (die ersten 15 Sekunden scheinen unvermeidlich zu sein), obwohl dies möglicherweise nicht immer einen "perfekten" Build garantiert, wie es SCons tut (obwohl das für inkrementelle Builds in der Entwicklung möglicherweise nicht wichtig ist ... ein würdiger Kompromiss).

Ich habe jetzt genug Wissen, um es wahrscheinlich durch npm und npm watch zu hacken ... und oder ein anderes System, mit dem ich derzeit nicht vertraut bin ... Aber das ist für später und wenn ich Zeit habe (derzeit nicht).

Das wird ein bisschen lang, also beende ich es hier, aber der Sinn dieser Absätze war, Ihnen einige "statistische" Informationen zu geben, anstatt jemanden zu entmutigen (machen Sie weiter, wenn Sie gerne an Build-Systemen arbeiten), wie ich es selbst mochte einige Sachen in Godots SCons repariert. Ich hoffe, ein paar Informationen waren hier hilfreich für euch.

Wenn Sie meine Statistiken replizieren / wiederholen möchten, durchsuchen Sie einfach die SCons-Dokumente, bis Sie statistische Informationen (Timer-Zeug) aktivieren und / oder einen Weg finden, die Abhängigkeitsneuauflösung zu deaktivieren (die ersten 20 bis 30-35 Sekunden der "Vorberechnung" )...

Oder für eine etwas weniger manuelle Lösung sollten Timer-Debugging-Informationen bereits vorhanden sein (Bearbeiten: Es ist wahrscheinlich nicht, jemand hat ein süßes Update für die vs-Projektgenerierung gemacht, dieser Absatz könnte veraltete Informationen sein) SCons (am Ende der SConstruct-Datei)... Informationen zum Generieren eines VS-Projekts finden Sie im "Tutorial zur Windows-Kompilierung" auf der godot-Website. Sie können dann SCons von VS ausführen, ich glaube, das generierte Projekt sollte wahrscheinlich immer noch funktionieren, obwohl ich es in Godot 3 nicht getestet habe ... ...

Ich hoffe, jemand fand diese Informationen hilfreich.

@Griefchief Nur um die Dinge ein wenig zu klären, ich denke, wir versuchen nicht, die vollständigen

Tatsächlich ist der "null inkrementelle Build" der Fall, an dem wir gerade arbeiten.

Einige Profiling hat einige Ineffizienzen bei der Verarbeitung der Befehlszeilen (die für jedes Ziel durchgeführt werden müssen, um sicherzustellen, dass sie sich nicht geändert haben) identifiziert. Der Großteil davon ist die Subst()-Logik. Dies ist ein kniffliger Code, der bisher auf einfachere und sicherere, aber nicht sehr effiziente Weise implementiert wurde.

Ein weiterer Hot Spot der Zeit ist das Lesen und Schreiben der sconsign-Dateien, die derzeit mit cpickle realisiert und immer als Ganzes gelesen und geschrieben werden. Wir haben einige Ideen, wie man entweder beschleunigen und/oder inkrementell machen kann. Beobachten Sie auf jeden Fall zukünftige Versionen für Verbesserungen.

Nebenbei bemerkt, können Sie MSVC_BATCH ausprobieren, um zu sehen, ob dies Ihre Windows-Builds beschleunigt:

MSVC_BATCH
Gibt bei Festlegung auf einen wahren Wert an, dass SCons beim Aufrufen des Microsoft Visual C/C++-Compilers eine Stapelkompilierung von Objektdateien durchführen sollen. Alle Kompilierungen von Quelldateien aus demselben Quellverzeichnis, die Zieldateien in demselben Ausgabeverzeichnis generieren und in SCons mit derselben Konstruktionsumgebung konfiguriert wurden, werden in einem einzigen Aufruf des Compilers erstellt. Nur Quelldateien, die sich seit der Erstellung ihrer Objektdateien geändert haben, werden an jeden Compileraufruf übergeben (über die Konstruktionsvariable $CHANGED_SOURCES). Alle Kompilierungen, bei denen der Basisname der Objekt- (Ziel-)Datei (abzüglich der .obj) nicht mit dem Basisnamen der Quelldatei übereinstimmt, werden separat kompiliert.

@bojidar-bg ja, ja, ich habe auch von inkrementellen Builds gesprochen, danke für den Tipp :D

@bdbaddog Hallo Baddog, nur zu Ihrer Info, ich habe diesen großen Kommentar von mir tatsächlich geschrieben, bevor ich Ihren Kommentar gesehen habe, also bezieht er sich eigentlich nicht auf etwas in Ihrem Kommentar speziell ... aber Sie haben es geschafft, einige der " Bedenken" hatte (eigentlich Informationen für andere Leute), während wir beide gleichzeitig unsere Kommentare schrieben...

Und ich wollte dich nicht anpingen, weil ich deine Zeit nicht "verschwenden" wollte :D, aber ich denke, ich werde in Zukunft etwas mehr Zeit mit Godot-Builds / Scons verbringen (ich habe vor, bin nur sehr beschäftigt))

Vielen Dank für Ihren Input hier!

@bdbaddog BD, da Sie Support leisten, wenn ich hier fragen darf:

Wenn ich npm watch an das Dateisystem (Godots Quelle) anhänge und weiß, welche Datei genau geändert wurde, würde mir das mit SCons Vorteile bringen?

Jetzt kann ich scons über npm watch ausführen und die Datei dorthin verschieben ...

scons [godot-Optionen] die/Datei/das/was/geändert wurde.

Dadurch wird diese Datei offensichtlich neu kompiliert, wodurch wahrscheinlich Godots gesamter dep-Baum vermieden wird? Korrekt? Die Durchquerung des Dep-Baums dauert jetzt also keine 20 Sekunden, sondern weniger als 1 Problem, aber ich erhalte 1 aktualisierte .obj-Datei (oder mehr, hängt davon ab, was Sie ändern). Es wird nicht wirklich den ganzen Godot-Dep-Baum für diese eine Datei durchlaufen? Ich habe in diesem Beispiel einen Vorteil bei der weniger tiefen Baumdurchquerung (und möglicherweise anderen Vorteilen in der Vorberechnungsphase, die nicht durch die Wiederverwendung des Dep-Tree-Cache erzielt werden können, wie insgesamt weniger Dateien, die durchlaufen werden müssen?)

Nun, wenn ich einen Vorteil habe und wenn ich einfach alles wieder verlinken wollte, bräuchte ich dann für eine "einfache" Verlinkungsphase eine vollständige Baumdurchquerung?

Ich verstehe, dass dieser Anwendungsfall derzeit möglicherweise nicht von Scons unterstützt wird (verlinken Sie einfach alles erneut), aber ich frage sowohl aus praktischer als auch aus theoretischer Sicht? Mir ist klar, dass der zwischengespeicherte Dep-Tree mit dieser Option "Do not do dep tree" wiederverwendet werden könnte (ich habe es vergessen, es ist zwei Jahre her), und das würde für einige Anwendungsfälle funktionieren, und dieser Anwendungsfall ist keine neuen Dateien hinzugefügt, richtig ? (npm watch könnte mich auf das Hinzufügen neuer Dateien aufmerksam machen und ich könnte dann eine vollständige Aktualisierung des Dep-Trees durchführen, wenn ich das erkenne ... Geben Sie die Option "Abhängigkeits-Cache verwenden" manuell in ein Programm wie npm watch ein. Lassen Sie das Programm sich um die Konsistenz kümmern, nicht den Benutzer, und tun Sie dies in "Echtzeit", sobald der Benutzer gespeichert hat Datei, was den Scons viel mehr Zeit gibt, ihre Sache zu erledigen)

Gibt es etwas in meiner Idee, das nicht als Optimierung funktionieren würde (praktisch und theoretisch), und haben Sie andere Vorschläge (die keinen perfekten Build garantieren müssen, wenn so etwas wie npm watch sich um Dinge kümmern kann, ist es auch in Ordnung?) )? Können Sie bitte raten? Dankeschön!

Um es noch einmal zusammenzufassen, der Anwendungsfall ähnelt diesem:

1) Führen Sie einen Filewatcher wie npm watch im Quellverzeichnis von Godot aus
2) Benutzer speichert/ändert eine alte Datei
3) scons wird sofort von npm für diese Datei ausgeführt.
4) Wenn die Kompilierung erfolgreich ist, weist npm scons an, den Linker auszuführen und die ausführbare Datei zu verknüpfen.

4.1) Wenn der dep-Baum kassiert wird (ein vollständiger Build wurde bereits ausgeführt), kann npm den Linker anweisen, an dieser Stelle nur mit einer zwischengespeicherten Version von dep-Baum zu verknüpfen
4.1) Wenn kein zwischengespeicherter Dep-Baum erkannt wird, führt npm watch einen vollständigen Godot-Build aus
4.2) Wenn eine Cache-Invalidierung festgestellt wurde, wie das Hinzufügen einer neuen Datei, führen Sie eine vollständige Durchquerung des Dep-Trees durch (npm verwendet nicht die Option "use cached dep tree" mit Scons).

Ich hoffe, das macht meine Idee etwas verständlicher, bitte lass mich an dieser Stelle wissen, was daran nicht stimmt ;D

PS Ich glaube, dies ist der Befehl, der den inkrementellen Build von 35 Nullen um 15 Sekunden reduziert, mit seinen "offensichtlichen" Konsequenzen ... wurde geändert, wenn das in irgendeiner Weise hilft (oder es helfen könnte)):

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

Also ein paar Dinge hier (in keiner bestimmten Reihenfolge, aber ich verwende Zahlen, weil yolo

1) Inkrementelle Null-Builds sind im Grunde nichts unter einem Tool, das Ninja-Dateien generiert. Chrome hat, AFAIK, einen inkrementellen Build von weniger als 2 Sekunden. Dies ist wichtig, da ein Rückgang von 35 Sekunden auf 15 unter einem npm watch im Vergleich zu einem meson- oder cmake-basierten Ninja-Build immer noch sehr groß ist. Ninja macht auch dasselbe wie Scons, indem es einen Neuaufbau durchführt, falls sich die Befehlszeile ändert (macht dies natürlich nicht).

2) CMake hat kürzlich die Möglichkeit implementiert, CONFIGURE_DEPENDS als Argument für das Glob-System zu verwenden. Dies wurde immer davon abgeraten, da Tools wie xcodebuild und msbuild historisch (und derzeit) die Erkennung von Verzeichnisänderungen nicht unterstützt haben. Dies ist zwar eine Sache, die Scons verbessern könnte, aber ich habe weder die Zeit noch die Geduld, um tief in das Projekt einzutauchen, um dies umzusetzen. Grundsätzlich aktualisiert jedes Betriebssystem ein Verzeichnis, wenn sich sein Inhalt ändert, sei es eine hinzugefügte Datei, eine geänderte Datei oder eine entfernte Datei. Bei inkrementellen Änderungen kann man einfach prüfen, welche Verzeichnisse sich geändert haben und nur diese bei einer Neukonfigurationsprüfung globen. Dies kann die geleistete Arbeit reduzieren, da Sie nicht den gesamten Baum, sondern kleinere Teile globben. Für kleine Projekte ist das in Ordnung. Ob dies Godot nützen würde oder nicht, würde einige Tests erfordern und das ist eine Menge Arbeit, um zu überprüfen, ob es überhaupt hilft.

3) Es ist zwar schön zu sehen, dass Scons mehr Aufmerksamkeit erfährt, aber ich persönlich denke, dass es für die gesamte Community besser ist, dass Godot zu einem mehr gebrauchten Build-System wechselt. Ich kann mir außerhalb von Godot kein großes Projekt vorstellen, das Scons verwendet. GNOME/GTK ist vor kurzem auf meson umgezogen (überspringt CMake), KDE ist seit geraumer Zeit auf CMake. Obwohl es sich um anekdotische Beweise (und damit um eine grundlegende Bestätigungsverzerrung) handelt, kenne ich mehrere C++-Entwickler, die Godot ausprobieren möchten, aber lieber nie wieder Scons anfassen müssen. Es ist schwierig, die unangenehmen Erfahrungen und damit den sauren Geschmack in den Mündern der Entwickler zu entfernen, und ich wünsche dem Scons-Projekt aufrichtig das Beste. Aber ich weiß, dass die C++-Community im Allgemeinen lange Kompilierzeiten hasst. Lange inkrementelle Null-Builds (oder sogar lange inkrementelle Builds von 1 Datei) sind in der modernen Welt ein Albtraum.

Ich beabsichtige, es noch einmal zu versuchen, aber ich könnte dafür CMake als Ziel verwenden. Der Wechsel von CMake zu meson ist viel einfacher, da meson ein Konvertierungsskript hat, das viel Arbeit erledigen kann. CMake könnte die Handhabung von Abhängigkeiten mit dem neuen FetchContent-Modul etwas einfacher machen. Wir werden sehen, wie es funktioniert. Ich werde sagen, ich bin froh, dass diese Codegen-Skripte in separate Dateien verschoben wurden. Die Verwendung von CMake ist schon deshalb schön, weil der Wechsel zu einem anderen C++-Standard so einfach ist wie target_compile_features(<target> (PUBLIC|PRIVATE|INTERFACE) cxx_std_<number>)

Natürlich wird alles, was mit dem Build-System zu tun hat, umstritten sein, aber es kann nicht schaden.

Um ganz ehrlich zu sein (und das mag gefühllos rüberkommen) habe ich keine Lust, tief in das Scons-Projekt einzutauchen, um es zu verbessern. Vielleicht nach 2020, wenn Python 2.7 offiziell endgültig tot ist und das Projekt zu Python 3.5+ übergehen kann, nur es lohnt sich, es zu untersuchen oder zu verbessern, möglicherweise mit asynchronen Operationen. Bis dahin möchte ich es aber lieber nicht anfassen.

Vielleicht nach 2020, wenn Python 2.7 offiziell endgültig tot ist und das Projekt zu Python 3.5+ übergehen kann, nur es lohnt sich, es zu untersuchen oder zu verbessern

Scons 3 unterstützt Python 3.5+: https://scons.org/tag/releases.html .

Ich verstehe nicht wirklich, wie man Scons so ablehnen kann und wie man das Konfigurations-Chaos von CMake mag, wo es sogar schwer ist, seine eigenen Build-Einstellungen zu definieren, wenn man ein Benutzer ist, schwer zu verstehen, was die Optionen und ihre Typen sind und was sind innerlich definiert, es hat mir nur Schmerzen bereitet und ich war wirklich erleichtert, dass Godot es nicht benutzt hat.

Auf jeden Fall, wenn Sie das Gefühl haben, dass dies eine bessere Lösung ist, versuchen Sie es einfach, ich könnte meine Meinung zu CMake ändern.

wo es sogar schwierig ist, eigene Build-Einstellungen zu definieren, wenn Sie ein Benutzer sind,

Wenn das gefragt wird, wird CMake falsch verwendet. Alle Toolchain-Einstellungen sollten sich in einer Toolchain-Datei befinden und alle projektspezifischen Konfigurationen werden über Flags (oder GUI oder Bearbeiten der Cache-Datei oder was auch immer) übergeben. Alles ist dokumentiert und typisiert, selbst die Projektautoren können ihre exponierte Konfiguration gut dokumentieren und eintippen. Sie sollten CGold und die modernen CMake-Standards lesen.

@Faless niemand bestreitet, dass die CMake-Sprache schrecklich ist. Aber die Umsetzung ist klasse. Ich habe die Möglichkeit in Betracht gezogen, einen Transpiler aus einer besseren Sprache zu schreiben, um das Problem zu lindern.

@OvermindDL1 liebt den Vorschlag, CGold zu lesen.

Wenn das gefragt wird, wird CMake falsch verwendet

Nun, ich vermute, dass alle Programme, auf die ich gestoßen bin, es damals falsch gemacht haben.

Um ehrlich zu sein, hasse ich es, Flags über -DI_LOVE_CMAKE_AND_MAKE_DEFINES_LONG=on ändern zu müssen (wirklich? on ?). Ganz zu schweigen von der Idee, die Cache-Datei O_o zu bearbeiten. Oder wenn ich ein Flag ändern möchte, muss ich im Grunde den Build-Ordner löschen und von vorne anfangen (weil sich der Cache unterscheidet!) ... so viel zu inkrementellen Builds ...

EDIT: Eine Sache, die ich an Scons wirklich mochte (zumindest in Godot, und dies könnte natürlich mit anderen Build-Systemen möglich sein), ist, dass ich keinen Standard oder kein Dokument gelesen habe, sondern nur scons -h im Godot-Ordner

95% der Build-Dateien, die ich auf GitHub gesehen habe, sind falsch. Die Leute werden faul beim Bauen von Systemen und folgen Cargo-Kult-Praktiken, um etwas zusammenzubasteln.

@isaachier , nur als Metrik, könnten Sie 2 Beispiele für eine schlechte und gute CMake-Datei bereitstellen? Wie würden Sie das betrachten: https://github.com/ARMmbed/mbedtls/blob/development/CMakeLists.txt ?

Besser als die meisten, die ich gesehen habe. Wenn Sie jedoch nicht CMake >= 3.0 verwenden, haben Sie keine Erfahrung mit modernem CMake.

Nun, ich vermute, dass alle Programme, auf die ich gestoßen bin, es damals falsch gemacht haben.

Ich sehe es heutzutage eher gut gemacht.

Um ehrlich zu sein, hasse ich es, Flags über -DI_LOVE_CMAKE_AND_MAKE_DEFINES_LONG=on (wirklich? an?) ändern zu müssen. Ganz zu schweigen von der Idee, die Cache-Datei O_o zu bearbeiten. Oder wenn ich ein Flag ändern möchte, muss ich im Grunde den Build-Ordner löschen und von vorne anfangen (weil sich der Cache unterscheidet!) ... so viel zu inkrementellen Builds ...

Sie müssen nicht on , Sie können true , 1 und viele andere Dinge verwenden. Es ist so zu machen, dass Sie einen geeigneten booleschen Namen auswählen können, der gut mit dem Flagnamen übereinstimmt.

Und Sie sollten den Build-Ordner nie neu erstellen müssen, wenn Sie Optionen ändern, cmake ist außergewöhnlich gut darin, bei Bedarf neu zu erstellen.

Trotzdem sollte jeder, der mit C/C++ Build-Systemen in Berührung kommt , sehr viel kürzer als gut zu verwenden. Die alten CMake2-Methoden sollten nicht verwendet werden. Wirklich, jeder, der auf eine CMake 2.x-Version angewiesen ist, macht absolut Dinge falsch (Ziele und Toolchains nicht richtig verwenden, Optionen nicht richtig einstellen usw. usw.).

Danke für die Erklärungen, während ich skeptisch bleibe, bin ich gespannt, wie es für Godot funktionieren würde :).

@slurps-mad-rips Ihr Beitrag mit dem vermeintlichen CMake-Beispielcode zum Aktivieren des C++11-Modus ist aus verschiedenen Gründen völlig nicht standardmäßiger CMake, einschließlich, aber nicht beschränkt auf:

• Festlegen von nicht exponierten Variablen.
• Toolchain-Argumente, die in einer Nicht-Toolchain-Datei festgelegt sind.
• Absolut nicht, wie Sie so etwas wie den C++11-Modus aktivieren.
• Ineffizient.

Angesichts des gezeigten selbstbeschriebenen-als-vereinfachten Meson-Codes in diesem Beitrag von:

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)

Das Äquivalent vereinfachtes (insofern Sie auch weitere Eigenschaften hinzufügen können) CMake wäre:

set_target_properties(godot PROPERTIES CXX_STANDARD 11)

Und das stellt sicher, dass die verwendete Toolchain weiß, dass sie diesen Modus setzen muss (und Sie können angeben, wie mit Fehlern umgegangen wird, wenn Sie einen Compiler verwenden, der dies nicht ebenfalls unterstützt). Angenommen, spezielle Compiler-spezifische Befehlszeilen-Flags in der Build-Datei sind extrem schlecht, da diese nur in Toolchain-Dateien vorhanden sein sollten und die Tatsache, dass das im vorherigen Beitrag gezeigte Meson-Beispiel tatsächlich spezifische Argumente angibt, bedeutet im Wesentlichen, dass Sie die unterstützten Compiler hartcodieren.

Wenn man bedenkt, dass es eine vorgefertigte CMake Toolchain-Datei für fast jede Toolchain gibt, die Sie sich vorstellen können (einschließlich aller Standards von MSVC in verschiedenen Varianten, GCC/Clang, Android, iOS, Emscripten usw sollte das Rad nicht neu erfinden. Wenn der Benutzer, der etwas wie Godot kompiliert, seinen eigenen benutzerdefinierten Compiler mit eindeutigen Befehlszeilenargumenten verwenden möchte (wie Intels Compiler oder vielleicht einen dedizierten Chip oder nur ein einfaches RPi), dann sollte sich das Build-Skript nicht darum kümmern oder überhaupt irgendwelche Änderungen benötigen (der Code könnte natürlich, aber im Optimalfall auch nie, da CMake ihm sagen kann, was alles über Definitionen unterstützt wird) und der Benutzer kann seine eigene benutzerdefinierte Toolchain-Datei für den Build bereitstellen.

EDIT: Und die weit verbreitete Unterstützung nie außer Acht lassen. Ich kann nichts darüber finden, dass Meson Projektdateien für KDevelop generieren kann (die von mir verwendete IDE, die interessanterweise CMake als Build-Format verwendet, ich verwende gelegentlich CLion bei der Arbeit, es verwendet auch CMake), wobei fast jede IDE ausgeht ( sogar Visual Studio!) kann CMake-Projekte jetzt nativ öffnen (zusätzlich dazu, dass CMake Projekte für die meisten IDEs direkt generieren kann, wenn Sie dies wünschen).

@OvermindDL1

Es ist nicht im geringsten kein Standard-CMake. Das Codebeispiel zielt auf CMake 3.0 ab, eine Version, in der CXX_STANDARD nicht vorhanden ist. Von hier aus können Sie leicht erkennen target_compile_features mit cxx_std_ und der Nummer des Standards verwenden. Dies ist die neue und moderne cmake-Methode, um die Standardversion einzustellen. set_target_properties ist ein älterer Ansatz pro Ziel.
Tatsächlich ist der genaue Code aus der Dokumentation von

target_compile_features(mylib PUBLIC cxx_std_11)

CXX_STANDARD jedoch nicht die libc++-Unterstützung für clang, da clang standardmäßig libstdc++ unter Linux verwendet, es sei denn, es ist konfiguriert, um standardmäßig libc++ auf den meisten Linux-Distributionen zu verwenden, da dies Linker-Fehler und ABI-Probleme verursachen würde) . Die einzige Möglichkeit, dies zu diesem Zeitpunkt zu tun, besteht darin, zu überprüfen, ob der Compiler -stdlib=libc++ und es über einen Generatorausdruck an den Compiler zu übergeben. Diesbezüglich gibt es nichts mit nicht exponierten Variablen.

Darüber hinaus schätze ich es nicht, dass Sie einen Kommentar hinterlassen, um Korrekturen an einem Kommentar vorzunehmen, den ich vor Monaten gemacht habe, zumal ich bei meinem nächsten Versuch CMake über Meson anvisieren werde. Es fehlt an Fingerspitzengefühl und trägt meiner Meinung nach nichts zum Gespräch bei.

CMake 3.0 ist alt genug, um nicht mehr unterstützt zu werden (10. Juni 2014). Niemand sollte derzeit weniger als CMake 3.10 ausführen, obwohl es im Moment bevorzugt wird, mit CMake 3.12 auf dem Laufenden zu bleiben.

Und ja, das von Ihnen angegebene Beispiel wird vollständig davon abgeraten (ich denke, sogar CGold erwähnt dies nicht).

Und ja, ich meinte target_compile_features. ^.^;

CXX_STANDARD legt jedoch keine libc++-Unterstützung für clang fest, da clang standardmäßig libstdc++ unter Linux verwendet, es sei denn, es wurde konfiguriert (und es ist nie so konfiguriert, dass libc++ standardmäßig auf den meisten Linux-Distributionen verwendet wird, da dies Linker-Fehler und ABI-Probleme verursachen würde). Die einzige Möglichkeit, dies zu diesem Zeitpunkt zu tun, besteht darin, zu überprüfen, ob der Compiler -stdlib=libc++ unterstützt, und es über einen Generatorausdruck an den Compiler zu übergeben. Diesbezüglich gibt es nichts mit nicht exponierten Variablen.

Die aktuellen Toolchains tun dies alle für Clang, zumindest mit C++14, da ich damit kompiliere (und ein paar C++17).

Außerdem schätze ich es nicht, dass Sie einen Kommentar hinterlassen, um Korrekturen an einem Kommentar vorzunehmen, den ich vor Monaten gemacht habe, zumal ich bei meinem nächsten Versuch CMake über Meson anvisieren werde. Es fehlt an Fingerspitzengefühl und trägt meiner Meinung nach nichts zum Gespräch bei.

Ich entschuldige mich, habe das Datum beim Lesen des Backlogs nicht bemerkt (und hier gibt es viel Backlog). Mir ist gerade etwas aufgefallen, das für jede Art moderner Vorschläge von dem, was ich seit ein paar Jahren gesehen habe, erbärmlich falsch erschien und kurz darauf keine Korrekturen in Posts sah, also wollte ich, dass sich die falschen Informationen nicht verbreiten. :-)

Die einzige Möglichkeit, dies zu diesem Zeitpunkt zu tun, besteht darin, zu überprüfen, ob der Compiler -stdlib=libc++ unterstützt, und es über einen Generatorausdruck an den Compiler zu übergeben.

Ja aber das ist die Aufgabe der Toolchain - Datei, die in einer Build - Datei absolut nicht immer angezeigt werden soll, niemals.

Diesbezüglich gibt es nichts mit nicht exponierten Variablen.

Ich habe nur auf die Variablen verwiesen, die gesetzt werden und dann an anderer Stelle nur an einzelnen Orten verwendet werden, was in CGold unter anderem aus verschiedenen Gründen empfohlen wird.

CMake 3.0 ist alt genug, um nicht mehr unterstützt zu werden (10. Juni 2014). Niemand sollte derzeit weniger als CMake 3.10 ausführen, obwohl es im Moment bevorzugt wird, mit CMake 3.12 auf dem Laufenden zu bleiben.

Sie sollten nicht, und doch sind es einige Orte. Für eine Spiel-Engine, die versucht, auf dem neuesten Stand und mit der neuesten Technologie zu bleiben, ist es in Ordnung, auf dem neuesten CMake zu bleiben. Mir sind jedoch sehr aktive Projekte bekannt, die auf älteren Versionen wie 3.5 und in einigen Fällen 3.4 hängen bleiben. Tatsächlich zielen einige bekannte C-Bibliotheken immer noch auf CMake 2.8 ab (siehe: SDL2, libssh2, libgit2 usw.).

Aber ja, das ist die Aufgabe der Toolchain-Datei, die auf keinen Fall jemals in einer Build-Datei erscheinen sollte.

Diese Annahme (dass Toolchain-Dateien gut geschrieben sind und alle möglichen Systeme und alle Versionen von CMake abdecken) macht Probleme im aktuellen allgemeinen C++-Ökosystem. Bei Verwendung von clang muss die Option zum Kompilieren für libstdc++ oder libc++ (insbesondere bei Verwendung über einen FetchContent Aufruf) von der Bibliothek bereitgestellt werden. CheckIncludeCXX und CheckCXXCompileFlag werden noch für einige Flags benötigt, die unter GCC nicht existieren, aber unter Clang existieren (und umgekehrt). Das Hauptproblem dabei ist, dass die Compiler-Schnittstellen stark voneinander abgewichen sind, und anstatt dass die Hersteller Zeit damit verbringen, Kompatibilitätsoptionen zu erleichtern oder sogar eine gemeinsame Schnittstelle zu diskutieren, wird dieses Verhalten auf uns, den Entwickler, aufgedrängt, wenn wir nur Code schreiben wollen. Vertrauen Sie mir, niemand auf diesem Planeten ist über den Zustand von C- und C++-Buildsystemen und das Abhängigkeitsmanagement mehr verärgert als ich, aber Pragmatismus für vorhandene Bibliotheken auf CMake ist erforderlich. Das Schöne am Wechsel von einem Build-System zu CMake ist, dass wir mit den neuesten und besten Funktionen beginnen können. Das Problem wird zur Stagnation des Build-Systems, weil niemand es anfassen möchte (außer dieser tapferen Seele, die die Build-Skripte für die Codegenerierung in separate Skripte geworfen hat), aber es wäre einige Arbeit erforderlich, um sicherzustellen, dass es nicht aus dem Ruder läuft (was es wird, weil ... ich meine, es ist ein Build-System. Das tun sie immer)

Ich muss der Typ sein, der es wirklich genießt, Build-Skripte zu schreiben, besonders in CMake ;).

Diese Annahme (dass Toolchain-Dateien gut geschrieben sind und alle möglichen Systeme und alle Versionen von CMake abdecken) macht Probleme im aktuellen allgemeinen C++-Ökosystem. Bei Verwendung von clang muss die Option zum Kompilieren für libstdc++ oder libc++ (insbesondere bei Verwendung über einen FetchContent-Aufruf) von der Bibliothek bereitgestellt werden.

Solche Dinge sollten Eigenschaften sein, die an die Toolchain übergeben werden, auf die die Toolchain dann reagieren kann.

Ebenso wie wenn Sie ein sehr einzigartiges Setup haben, ist es durchaus vernünftig, Toolchain-Dateien einzubinden, beispielsweise für einen sehr benutzerdefinierten Android-Build oder so (obwohl der erweiterte Polly-Satz von cmake-Toolchains fast alles abdeckt, was ich bisher benötigt habe).

Das Problem wird zur Stagnation des Build-Systems, weil niemand es anfassen möchte (außer dieser tapferen Seele, die die Build-Skripte für die Codegenerierung in separate Skripte geworfen hat), aber es wäre einige Arbeit erforderlich, um sicherzustellen, dass es nicht aus dem Ruder läuft (was es wird, weil ... ich meine, es ist ein Build-System. Das tun sie immer)

Dies ist eigentlich ein großartiger Punkt, um sich jetzt für CMake zu entscheiden, es hat eine gut definierte Reihe von Standards, die jetzt wirklich gut funktionieren, nachdem man sich mit mehr als einem Jahrzehnt Erfahrung, sowohl guten als auch schlechten, beschäftigt hat.

Ich muss der Typ sein, der es wirklich genießt, Build-Skripte zu schreiben, besonders in CMake ;).

Ich genieße es im Vergleich zu Alternativen auf jeden Fall, obwohl ich lange genug darin geschrieben habe, dass es für mich Sinn macht, obwohl das definitiv nicht bedeutet, dass es für jeden so wäre. ^.^;

Ich habe im Laufe der Jahre viele verschiedene Build-Systeme verwendet. Das, was für mich in letzter Zeit am sinnvollsten war, ist CMake, aber ich kann definitiv den Reiz von SCons und seine Flexibilität sehen.

Auch wenn SCons nicht perfekt ist (welches Build-System ist das?), kann es gut genug sein.

• Bietet es die erforderlichen Funktionen?
• Wie viel Overhead entsteht?

Wenn SCons für beide Punkte "gut genug" ist, dann behalte es.

Hat sich jemand von Ihnen, der vorgeschlagen hat, SCons durch etwas anderes zu ersetzen, tatsächlich die Mühe gemacht, zu lernen, wie das Godot-Build-System funktioniert?

Als Hinweis, es ist unglaublich komplex und ich glaube nicht, dass es viele (oder irgendwelche) Projekte gibt, die CMake-Building für so viele Plattformen verwenden und es ermöglichen, mehrere Build-Ziele gleichzeitig zu konfigurieren / zu kompilieren, wie wir es tun.

Alle Bemühungen derer, die sagten, "Ich werde das Godot-Build-System auf etwas anderes portieren", sind bisher kläglich gescheitert, als sie die Komplexität dessen erkannten, worum sich SCons kümmert.

Für mich ist es mit Abstand das beste Werkzeug für den Job. Nichts ist auch nur in der Nähe. Wenn Sie sich über die Basiskompilierungszeit beschweren (die auf einem mittleren bis High-End-System mit SSD nur 4/5 Sekunden beträgt), sollten Sie wirklich zuerst versuchen, alles zu verstehen, was Godot beim Erstellen tut, und sehen, wie es in CMake oder irgendetwas anderem funktionieren würde .

Ich habe nachgeschaut. Ich bin nicht davon überzeugt, dass es in CMake oder anderswo rückgängig gemacht werden kann. Aber ich bin auch faul ;). Mal sehen was passiert.

Als jemand, der den Bazel-Port gemacht hat. Ich konnte an den Punkt gelangen, an dem der Godot-Editor ohne Symbole begann.

Ich bin mir ziemlich sicher, dass CMake diesen Punkt erreichen kann.

PS. Das nächste Konkurrenzprojekt mit vielen Plattformen ist Urho3d.

Ich habe mein Bazel-Ergebnis auf cmake reproduziert.

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

Angenommen Visual Studio 2017 ist installiert.

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

cmake installieren

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

Bitte spielen Sie damit. Der Editor hat die gleichen Probleme wie der Bazel-Build (keine Symbole), aber dieses Beispiel kann hilfreich sein.

Notiz

• Symbole funktionieren ab 71175b45f819e7cc5e4368dbf3e42abdd19af542
• Visual Script und GDscript funktionieren

@feuer Danke dafür. Ich sehe viele Verbesserungsmöglichkeiten, die die Wartung dieser CMake-Dateien erleichtern würden (und Zeitaufwand für das Hinzufügen neuer Funktionen oder Compiler-Flags). Ich könnte dies jedoch am nächsten Wochenende in Angriff nehmen, der Zeitplan steht noch aus.

Tolle Arbeit @fire. Schön zu sehen, dass hier jemand etwas in mehr als nur einem Build-System produzieren kann: smile:.

Leichtes Update. Ich hatte heute etwas Ausfallzeit, um den Aufbau von @fires Arbeit in Angriff zu nehmen. Leider sind die Codegenerierungsskripte immer noch ein wenig zu stark in das aktuelle Scons-System eingebettet und es ist einige Arbeit erforderlich, um sie vollständig zu befreien (dies setzt natürlich voraus, dass ich den Code richtig lese). Das heißt, es wird wahrscheinlich ein separates Problem + Pull-Request sein. Ich habe einige Bereiche identifiziert, in denen eine externe Vorlagendatei (oder eine Reihe von Vorlagendateien) verwendet werden könnte. Python unterstützt Vorlagen-Strings und dies könnte das Leben etwas einfacher machen, anstatt Strings verarbeiten zu müssen, sie einer Liste hinzuzufügen und dann weitere Strings zu verarbeiten und sie einer Liste hinzuzufügen usw. usw.

Idealerweise sollten die Skripts zur Codegenerierung ohne Kenntnis des Builds ausgeführt werden können, als wären sie ausführbare Dateien. Solange ihnen die richtigen Dateien übergeben wurden, können wir eine vollständige Portierung auf jedes andere Build-System vornehmen.

@slurps-mad-rips Es ist auch in SCons eine gute Idee, das aus Ihrem SCons-System zu entfernen. Sie können die GIL aufhängen, indem Sie zu viel Logik im Prozess haben und Ihre Build-Leistung beeinträchtigen. Gelegentlich führt dies beim parallelen Erstellen zu einigen Race-Bedingungen zum Schließen/Öffnen von Dateien (obwohl dies oft durch Öffnen der Datei in einem Kontext behoben wird).

Hallo alle,

Ich werde diesen Bereich nutzen, um die Leute über den Port zu CMake auf dem Laufenden zu halten. Wenn gewünscht, werde ich ein separates Thema erstellen und die Änderungen dort verfolgen, obwohl dies ein schöner Bereich ist, da es einen massiven Diskussionsrückstand gibt und ich denke, es wäre eine Verschwendung, so viel Kontext zu verlieren.

Ich schweife ab. Ich werde für die nächste Woche eine Pause von der CMake-Portierung einlegen müssen, während ich an einer Konferenz teilnehme, aber Sie können die Bemühungen meines ersten Portierungsversuchs hier sehen . Bitte denkt daran, dass ich drehe, um 1:1 beim aktuellen Master-Zweig zu bleiben, und daher werde ich Änderungen erzwingen, sobald sie eingehen, damit ich eine Rebase durchführen kann. Wenn ich mich der Stabilität nähere, werde ich einen Pull-Request einreichen, um die Arbeit mit Rebases zu erleichtern und es einfacher zu machen, Änderungen zu kommentieren oder Fragen zu stellen. Ich denke, dass diese Portierung auf CMake nicht nur machbar ist, sondern zumindest eine weitere Person (mich) damit vertraut machen wird, wie Godot tatsächlich gebaut und konstruiert ist, und ich kann das vielleicht in Worte fassen, damit andere es verstehen können eine Vogelperspektive des Build-Systems. Diese Portierung könnte möglicherweise auch auf lange Sicht den Arbeitsablauf aller erleichtern, insbesondere bei Releases. Ich werde nicht lügen, das CONFIGURE_DEPENDS Globing von Dateien gemischt mit Ninja ist eigentlich ganz nett.

Eine letzte Sache, ich empfehle Ihnen dringend, einen Blick auf die CMake- Hilfsmodule zu werfen, die ich geschrieben habe, nur weil, wenn Sie andere CMake-Projekte schreiben, diese Module nützlich sein könnten.

Konnten Sie auf die neueste 3.1-Alpha aktualisieren? Das Alpha könnte ein gutes Ziel sein. Versucht gerade den Build.

Der Titel dieser Ausgabe lautet: Ziehen Sie in Erwägung, das Buildsystem nach Meson zu verschieben . Ich halte es für unangemessen, hier über CMake zu diskutieren. Die Diskussion über CMake sollte ein eigenes Thema haben. Der Vergleich von Meson mit allem anderen ist in Ordnung.

@zaniar In diesem Thread wurde viel über Build-Systeme im Allgemeinen diskutiert. Nur weil der Titel nicht aktualisiert wurde, heißt das nicht, dass wir plötzlich eine neue Ausgabe erstellen und den gesamten Diskussionskontext verlieren und von vorne beginnen. Ich halte es für unangemessen, uns aufzufordern, monatelange Diskussionen plötzlich wegzuwerfen.

@fire Ich war die letzten Wochen mit der Arbeit beschäftigt, ich habe eine große Deadline für Freitag und dann habe ich vielleicht etwas Zeit, um meinen Fork auf den neuesten Stand zu bringen. Ich habe ein paar Änderungen vor Ort, die ich vergessen habe, nach oben zu schieben, aber ich habe gerade keine Zeit. (Zwischen dieser Portierung des Build-Systems, meiner Abzweigung von gnu m4, 15 Vorschlägen, die ich für das Treffen der C++-Standards in San Diego und die CppCon in der letzten Woche des Monats

Ja, Meson war das ursprüngliche Diskussionsziel, aber ich denke, es ist irgendwie natürlich, dass seitdem andere Build-Systeme angesprochen und diskutiert wurden, und es ist wahrscheinlich sinnvoll, die Diskussion hier in diesem Thema zu belassen, anstatt sie zu verbreiten, wie @slurps -Mad-Rips sagte.

Ich bin damit einverstanden, zu CMake zu wechseln. Es hat viel Unterstützung mit seinen Toolchains. Android-Builds werden zum Beispiel sehr einfach im Vergleich zu dem, was Godot in seiner SCsub-Datei macht, die für mich "nicht wartbar" aussieht.

Als Open-Source-Projekt sollte Godot Lösungen verwenden, die einfach zu warten sind und die die Mitwirkenden eher kennen und zu denen sie beitragen können.

Ich denke auch, dass dies für die GDNative-Akzeptanz wichtig ist. Unabhängig davon, welches Build-Tool verwendet wird, muss ein Beispiel- oder Standardprojekt mit leicht modifizierbarem Build-Skript vorhanden sein, das das Erstellen für alle Plattformen unterstützt, einschließlich iOS, Android usw.

Auch normale Module sollen als Shared Libraries kompiliert werden können. Dies hängt mit #19486 zusammen, sodass die Engine in mehrere herunterladbare Komponenten unterteilt werden kann.

Ich gehe diese tatsächlich an. Ich habe meine Änderungen schon eine Weile nicht mehr hochgeschoben, weil ich mit der CppCon beschäftigt war, dem bevorstehenden C++-Standardtreffen, und wir werden nächste Woche bei der Arbeit eine Version veröffentlichen. Es genügt zu sagen, dass ich nicht viel Zeit hatte, um die Portierung abzuschließen, aber die meiste Zeit werde ich damit verbringen, die Python-Skripte zu kopieren, die in Zukunft C++-Code generieren. Ich hoffe, dass ich dieses Wochenende die Arbeit an meinem Hafen wieder aufnehmen kann. Ich überlege derzeit, ob ich automatisch Abhängigkeiten von Drittanbietern erwerben und im Repository gespeicherte Patches anwenden soll oder nicht. Eine Frage , die ich für die Kern - Entwickler tun muß , ist , wie offen sie alle die third_party repos aus dem Haupt Repo- und in ihre eigenen Repositorys zu brechen an der Organisation wären. Ich verlasse mich in meinen eigenen Projekten ziemlich stark auf FetchContent , und ich wünschte derzeit, ich könnte dies für diese Abhängigkeiten von Drittanbietern tun, die leicht gegabelt wurden. Dies würde mich auch an jedem einzelnen arbeiten lassen, um seine cmake-Dateien zu bereinigen und gleichzeitig inkrementelle Änderungen am Core-Repository vorzunehmen, sobald jede Drittanbieterbibliothek portiert wurde.

Außerdem sollte beachtet werden, dass ich versuche, auch die Engine selbst zu modularisieren, sodass diese Komponenten technisch getrennt voneinander aktualisiert werden könnten, wenn jemand dies wünschte. Dies könnte das von @chanon erwähnte Problem

Schließlich füge ich Unterstützung für einige zusätzliche Build-Tools für die Kernentwickler hinzu, wenn sie auf dem System gefunden werden. Dinge wie clang-format, clang-tidy, ccache oder sccache, distcc, clang-check, address sanitizer, ubsanitizer, thread sanitizer usw. Dies sind meistens Linters (und könnten bei einigen Leuten die Köpfe explodieren lassen mit den Warnungen und verschiedenen Fehlern, die sie ve erkannt wurde), aber sie können optional aktiviert werden. Zumindest die Verwendung von sccache oder ccache bringt eine gewisse Verbesserung des Builds, wenn zwischen Builds und umgekehrt gewechselt wird. Es wäre schön, auf die Veröffentlichung von CMake 3.13 zu warten, da dies einige der Kludge-Arbeiten lösen würde, auf die ich mich verlassen musste, aber das Wichtigste ist, dass ich es so einrichte, dass der aktuelle "Erste Schritte"-Workflow ist pip install über Python 3.5 oder höher laufen zu lassen, aber es wird sich in einer virtuellen Umgebung befinden, damit die Leute sich nicht mit ihrer Systemumgebung herumschlagen müssen. (Dies würde es anderen auch ermöglichen, mit der Verwendung zusätzlicher Python-Bibliotheken als Abhängigkeiten für verschiedene Codegenerierungsskripte zu experimentieren und nicht daran denken zu müssen, sie später zu deinstallieren.)

Wie auch immer, sorry für den plötzlichen Info-Dump des Updates. Ich setze mich dafür ein, diesen Port fertig zu stellen, aber in letzter Zeit ist das Leben dazwischen gekommen 😅

Ich verlasse mich in meinen eigenen Projekten ziemlich stark auf FetchContent, und ich wünschte derzeit, ich könnte dies für diese Abhängigkeiten von Drittanbietern tun, die leicht gegabelt wurden.

Sie könnten auch Hunter verwenden und ein Godot-spezifisches Code-Repository erstellen (ein spezielles Git-Repo, wie zum Beispiel auf github) und auf diese Weise auf alle Abhängigkeiten zugreifen, da es das Erstellen, Cachen usw (oder übergeben Sie alle Abhängigkeiten an das 'Haupt'-Hunter-Paket-Repository und verwenden Sie es einfach direkt). Hunter ist nur eine einzelne cmake-Datei (HunterGate.cmake) und ein Aufruf zum Abrufen der Paket-Repository-Informationen (ob die offizielle oder eine benutzerdefinierte).

Eine bescheidene Bitte: Der Kommentarthread dieser Ausgabe ist riesig geworden - könnte jemand, der sie verfolgt hat, die bisherige allgemeine Diskussion in einem Kommentar zusammenfassen (und vielleicht könnte sie aus dem ersten Beitrag von @RiverMesa verlinkt werden)?

Hallo alle zusammen. Ich habe vor, Godot als meine nächste Engine für die Erstellung eines kleinen Spiels zu verwenden.

Ich habe dieses Gespräch gesehen und als Person, die Erfahrung mit CMake und Meson hat (und Autotools, Tup, Plain Make, Waf, SCons, vollständige Projekte in all diesen Tools ausprobiert ...) wollte ich mein Feedback geben.

Die Systeme, die ich intensiver genutzt habe, waren Autotools, CMake und Meson. Ich habe Meson und CMake in den letzten Jahren verwendet, da ich alle anderen Build-Systeme in Produktions-Setups bereits verworfen habe.

Vorteile von cmake

• Ausgereifte Projektgeneratoren, wenn Sie sich für Visual Studio interessieren (ich denke, Meson unterstützt es heutzutage gut, habe es aber in letzter Zeit nicht ausprobiert) und insbesondere XCode (ziemlich sicher, dass es hier mehr fehlt).
• Breitere Akzeptanz, mehr Unterstützung in IDEs
• Breitere Akzeptanz -> einfacher, Beiträge zu erhalten (obwohl Meson ein Kinderspiel ist, muss ich sagen)

Vorteile von Meson

• viele nützliche Ziele standardmäßig: Desinfektionsmittel, Unity-Builds kostenlos, vorkompilierte Header kostenlos, Abdeckung kostenlos ...
• die Dokumentation macht der CMake-Dokumentation einen Strich durch die Rechnung:
• Ich fand Cross Compilation viel einfacher
• Meson hat einen offensichtlichen Weg, alles zu tun

Welche würde ich wählen? Ich würde Meson wählen, wenn die Kreuzkompilierung intensiv ist und Sie auf schnelle Kompilierungszeiten achten (Unity-Builds und vorkompilierte Header werden standardmäßig unterstützt).
Ich würde CMake in Betracht ziehen, da es der Standard ist und Beiträge für das Team vielleicht wichtig sind. Ich würde mich persönlich für Meson entscheiden, aber das ist nur eine persönliche Meinung, da ich das Tool einfach besser finde und das spart mir meine eigene Zeit (CMake-Scripting, Space-Handling, Generator-Expressions, etc... ich schaue auf euch).

Entschuldigung für diese schamlose Eigenwerbung unten, aber ich denke, dass der Kontext danach schreit.

Ich habe hier eine kleine Artikelserie über mehr oder weniger grundlegendes Meson, falls jemand neugierig ist (4 Artikel):

• 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

Ich habe eine (etwas veraltete) Antwort zu Build-Systemen in StackOverflow:

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

Nur meine zwei Cent :)

@germandiago Das ist eine großartige Zusammenfassung - ich verfolge dieses Thema schon eine Weile und es wäre wunderbar, wenn ich mit Godot + CLion arbeiten könnte, was leider nur CMake ist.

Ja, die meisten modernen IDEs sind entweder nur CMake und / oder ein benutzerdefiniertes Build-System und / oder "rohe Aufrufe", die viele Funktionen verlieren. CMake ist wirklich zum Standard geworden, ob es nun verdient ist oder nicht.

@dorkbox Wenn ich diese Änderungen, an denen ich arbeite, bekomme, können Sie definitiv in einem CLion-Workflow (cmake + ninja) arbeiten.

@germandiago

Tatsächlich bin ich jetzt (mehr oder weniger 😛) mit dem Autor von meson seit der CppCon 2018 befreundet. Wir haben beide das gleiche Papier für das kommende Treffen zu Modulen mit dem Titel "Remember the Fortran" gefunden, und ich werde präsentieren sein Papier bei besagtem Treffen (eigentlich ist es nächste Woche!), und wir waren auch auf der CppCon im selben Build-Systems-Panel.

Ich würde gerne Meson verwenden. Wenn Sie weiter oben im Thread lesen, hatte ich eine Meson-Portierung versucht, aber die Dinge waren damals zu sehr in Scons integriert. Ich ziehe die aktuellen Codegenerierungsskripte immer noch als separate "ausführbare" Skripte heraus, so dass ein Wechsel zu Meson in Zukunft nicht in Frage kommt. Es ist jedoch eine langsame Arbeit, und ich habe ein paar Jinja-Vorlagen geschrieben, um bei der Codegenerierung zu helfen, damit Scons vollständig weggelassen werden können. Obwohl mein öffentlicher Fork veraltet ist, ist der, den ich zu Hause habe, etwas weiter vorne (und mit einem privaten Fork synchronisiert). Die Arbeit ist leider im Weg und San Diego wird mir leider mehr Zeit 'stehlen'. Danach sollte es mir jedoch frei sein, einige der lokalen Experimente, die ich auf meiner privaten Gabel habe, zu entfernen und endlich wieder in den Godot-cmake-Zug einzusteigen. Ich setze mich dafür ein, dass ein vollständiger Pull-Request eingehen kann, ohne dass auch der aktuelle Workflow-Prozess massiv gestört wird.

(Nebenbei: Danke an alle für die Geduld, die Sie hatten, während ich daran arbeite. Ich weiß, es ist schon eine Weile her, seit ich damit angefangen habe, aber ich vertrete jetzt meinen Arbeitgeber für die US National Body für das C++ Standards Committee, also mein Zeitplan war in letzter Zeit etwas voller, zumal wir wichtige Themen wie Module, Coroutines und Ranges angesprochen haben)

Ja, die meisten modernen IDEs sind entweder nur CMake und / oder ein benutzerdefiniertes Build-System und / oder "rohe Aufrufe", die viele Funktionen verlieren. CMake ist wirklich zum Standard geworden, ob es nun verdient ist oder nicht.

Ein mögliches nützliches Werkzeug für die Verwendung von Meson mit IDEs:

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

Es lässt die IDE denken, dass sie CMake verwendet, verwendet aber wirklich Meson unter der Haube.

Einige Hintergrundinformationen: Ich war viele (10?) Jahre lang ein großer Befürworter von CMake, habe mich aber letztes Jahr oder so in Meson verliebt. Meson scheint mit der Absicht geschrieben worden zu sein, die nützlichen Funktionen von CMake zu haben und gleichzeitig viele der Ärgernisse von CMake zu beheben / zu verhindern. Ein Hindernis, mit dem ich derzeit bei der Einführung von Meson in einem Projekt konfrontiert bin, ist die IDE-Unterstützung. Ich habe gerade das obige Tool entdeckt, vielleicht hilft das.

Jedes Build-System hat seine großen Mängel, mehr noch, es gibt keinen Grund, dies aus technischer Sicht zu ändern, sei es Scons, Autotools, Cmake, Meson oder was auch immer deine Religion gegen Ninja ist. Ich denke, es wäre großartig, alle anderen Build-System-Änderungsfehler als Duplikat dieses Fehlers zu schließen.

<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

Beweisen Sie, dass Reduz falsch ist @slurps-mad-rips :).

800lb Gorilla im Raum, der noch nicht erwähnt wurde. Einer von Godots Berühmtheitsansprüchen ist die plattformübergreifende Kompatibilität. Daraus sollte folgen, dass jedes Build-System, auf das eine Migration möglich ist, auf allen Plattformen, auf die Godot abzielt, verfügbar und getestet werden sollte. Wer auch immer hinter einer solchen Migration steht, sollte geneigt sein, die Migration auf allen unterstützten Plattformen zu testen oder zumindest Teil eines Teams zu sein, das dies tut. Sonst würde ich einen solchen Schritt als Widerspruch zur Godot-Philosophie und generell als eine schlechte Idee ansehen.

@lazybullfrog Ich habe Zugriff auf etwa 5 separate Computer für Desktops und mehrere mobile Geräte. Ein Teil meiner Portierung auf cmake stellt sicher, dass cmake-Toolchains für alle aktuellen Plattformen verfügbar sind.

@slurps-mad-rips Ist einer dieser Haiku? Wenn nicht, helfe ich gerne beim Testen. Vielen Dank.

Ein Teil meiner Portierung auf cmake stellt sicher, dass cmake-Toolchains für alle aktuellen Plattformen verfügbar sind.

Vergessen Sie auch nicht, dass es wahrscheinlich eine vorgefertigte Toolchain unter https://github.com/ruslo/polly gibt, wenn Sie cmake-Toolchains für eine Plattform benötigen, und wenn nicht, sollten Sie sie veröffentlichen. :-)

@slurps-mad-rips Wie ist es gelaufen? Mir ist aufgefallen, dass Sie den Code am 14. Januar aktualisiert haben. Ich habe versucht, unter Windows zu kompilieren, aber pkgconfig wurde nicht gefunden.

@fire life hat beschlossen, mir ein paar Curveballs in den Weg zu werfen und ich musste mich um sie kümmern. Persönliches leider. Ich habe mich auf die Arbeit konzentriert und die IXM-Bibliothek fertiggestellt, die ich verwende, um den Arbeitsaufwand zu reduzieren, der in Godot kopiert würde. Zum Glück mache ich in einer Woche Urlaub (ich fahre dieses Wochenende zum WG21 ISO-Meeting dieses Wochenendes nach Kona), also habe ich etwas Freizeit, um daran zu arbeiten, und (hoffentlich!) habe ich ein funktionierender Build für macOS, Linux und Windows bald™. Android und iOS, gefolgt von FreeBSD und Haiku (sorry @lazybullfrog , obwohl Sie gerne früher/oft testen können) werden danach meine nächste Priorität sein.

Der größte Arbeitsblock/Blocker bestand bisher darin, die Python-Skripte in "installierbare" Tools zu extrahieren, die von Scons getrennt sind und wie Prozesse ausgeführt werden. Das eigentliche Erfassen von Abhängigkeiten, Einstellungen usw. ist im Vergleich einfacher.

@slurps-mad-rips, das Leben hat mir auch ein paar Kurvenbälle zugeworfen. Vielleicht sollten wir ein Baseballteam gründen. 😂

Glücklicherweise war eine dieser Kurvenkugeln seit meinem letzten Kommentar ein 8-Kern-Xeon mit 32 GB RAM, auf dem Haiku und FreeBSD installiert waren. Vielleicht habe ich bald Zeit, beides zu testen.

Ich bin wirklich begeistert, dass diese beiden Plattformen Aufmerksamkeit erregen. Freuen Sie sich auf baldiges Testen.

Ich denke, es ist vernünftig, mehrere Build-Systeme zu haben. Vielleicht ein offizielles Build-System, das gut unterstützt wird, und die anderen werden auf einer "Sie finden es heraus"-Basis bereitgestellt. Benutzer werden trotzdem ihr eigenes Build-System verwenden wollen, warum also nicht ihre Arbeit an einem Ort bündeln?

Ich wäre bereit, einen Bazel-Port beizutragen, wenn die Dinge so laufen.

Ich denke, es ist vernünftig, mehrere Build-Systeme zu haben. Vielleicht ein offizielles Build-System, das gut unterstützt wird, und die anderen werden auf einer "Sie finden es heraus"-Basis bereitgestellt. Benutzer werden trotzdem ihr eigenes Build-System verwenden wollen, warum also nicht ihre Arbeit an einem Ort bündeln?

Als Linux-Packager habe ich Hunderte von Projekten mit verschiedenen Buildsystemen gesehen. Ich habe einige gesehen, die mehrere Buildsysteme zur Verfügung hatten. Ich habe noch nie einen gesehen, bei dem es nicht ein völliges Durcheinander war, besonders wenn die alternativen Buildsysteme von erstmaligen "Bitte fügen Sie CMake it's so cool"-Mitarbeitern bei, die dann aus dem Projekt verschwanden, und die Betreuer sich nicht die Mühe machten, es zu aktualisieren.

Es gibt keinen Wert überhaupt mehrere buildsystems unterstützen, und ich werde jede PR nicht fusionieren in diese Richtung gehen. Ich bin einer der Hauptverwalter von Buildsystemen und ich möchte definitiv nicht die Last haben, alternative zu warten, wenn wir etwas ändern müssen.

Wir haben derzeit ein Buildsystem, das für alle funktioniert und gut unterstützt wird und keine Änderungsabsicht hat. Wenn jemand wirklich andere Möglichkeiten untersuchen möchte, kann dies gerne tun, und wenn das Endergebnis auch für alle funktioniert, gut unterstützt werden kann und einen Mehrwert ohne große Nachteile bietet, werden wir es in Betracht ziehen.

Wenn jemand _wirklich_ andere Möglichkeiten untersuchen möchte, kann dies gerne tun, und wenn das Endergebnis auch für alle funktioniert, gut unterstützt werden kann und einen Mehrwert ohne große Nachteile bietet, werden wir es in Betracht ziehen.

Das habe ich mit meinem CMake-Port gemacht. Derzeit dauert eine No-Op- oder einzelne Dateiänderung unter scons auf meinem aktuellen Computer (der über 64 GB RAM, einen vergleichbaren Prozessor usw. verfügt) mehr als 10 Sekunden. Mit Ninja + cmake dauert der gesamte Konfigurations- + Generierungsprozess weniger Zeit und der Ninja build wird in weniger als 0,2 Sekunden in einem No-Op-Build beendet (unter Windows, wo das Starten eines Prozesses teuer ist). Ich kann auch das sccache- Tool von Mozilla verwenden, wenn es installiert ist, und das war äußerst nützlich, um die Codegen-Teile zu bearbeiten / einen neu generierten Build von Grund auf neu auszuführen, um sicherzustellen, dass nichts von meiner lokalen Umgebung abhängt.

Die meiste Zeit habe ich damit verbracht, die Codegenerierungsskripte in Python-Skripte zu extrahieren, die eigenständig ausgeführt werden können. Wenn das das einzige wäre, was zu Godot verschmolzen wäre, wäre meine Zeit, die ich dafür aufgewendet habe, keine totale Verschwendung. Es löst auch den run_in_subprocess Hack, der derzeit existiert, um Probleme mit Windows mit Parallelisierung zu lösen.

Ich bin gerade von meiner Reise zurückgekehrt und konnte ein bisschen arbeiten. Im Moment muss ich noch ein paar Dateien von einem manuellen Scons-Lauf kopieren, aber ich habe im Laufe der Zeit an den generierten Quellen herumgehackt. Die Header license.gen.h und method_bind.inc sind derzeit mein größtes Ziel, aber ich brauche ein paar Tage, um mit Jetlag + Arbeit fertig zu werden, bevor ich sie anpacke.

( Ich werde auch nur @fire cc lassen, da er sich für diesen Fortschritt für eine

Meiner Erfahrung nach ist Meson beim Erstellen von Android unter Windows völlig fertig, ich kann es einfach nicht zum Laufen bringen, eine der Bibliotheken von Drittanbietern zu kompilieren, die es verwenden (libepoxy). Und ich denke, es ist zu sehr an konkrete Compiler-Zeug gebunden.

Alles, was ich mir wünsche, ist ein Build-System, das Projektdateien und Datenbankdateien getrennt vom Build-Befehl generieren kann.

Jedes Mal, wenn ich einen neuen Branch mit größeren Änderungen an Dateien auschecke, muss ich Scons über die Befehlszeile ausführen, um meine vsproj-Dateien neu zu generieren, was auch dazu führt, dass sowieso ein vollständiger Build ausgeführt wird. In Scons gibt es nach dem, was ich gesehen habe, keine Projektgenerierungsstufe irgendeiner Art. Aus diesem Grund unterstützt es auch nicht das Erstellen von Kompilierungsdatenbanken für die Verwendung in Clang-Tools.

Derzeit ist die einzige praktikable Lösung zum Codieren von Godot unter Windows (IDE-weise) mit Visual Studio, ansonsten seien Sie darauf vorbereitet, nur einen Texteditor zu verwenden.

Scons ist wunderbar und alles, aber wenn ich einen 12-Kern-Threadripper und 128 GB RAM habe und auf Windows 12+ Sekunden warten muss, um eine einzelne Zeilenänderung zu kompilieren (das meiste davon denkt Scons), wird es ein bisschen nervig.

Aber der wirkliche Nachteil von Scons (und das könnte meine Faulheit beim Suchen sein) ist, dass ich keine einzelnen cpp-Dateien kompilieren kann. In der Lage zu sein, einzelne cpp-Dateien zu kompilieren, ohne das gesamte Projekt zu erstellen, ist ein enormer Produktivitätsschub und eine Gesundheitsprüfung.

Es sind nicht nur Linienänderungen, die Zeit brauchen, auch herauszufinden, ob etwas zu bauen ist, braucht Zeit ...

Ausführen von 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

Wenn Sie nur eine einzelne Zieldatei erstellen möchten, geben Sie dies in der Befehlszeile an

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

Ich wollte nur hinzufügen, dass die neueste Version von CMake einige der fehlenden Funktionen hinzufügt, die zuvor als Gründe erwähnt wurden, sie nicht zu verwenden.
Unity-Builds: https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html
Vorkompilierte Header: https://cmake.org/cmake/help/latest/command/target_precompile_headers.html

@Nosliwnayr Beide werden seit vielen Jahren von Addons unterstützt, sie sind gut getestet und wollten jetzt genug, um aufgenommen zu werden. Das waren nie Gründe, CMake nicht zu verwenden, da Sie beides in CMake schon sehr lange tun können.

@bdbaddog
Ich verstehe nicht, muss ich jede einzelne Datei manuell spezifizieren? Was macht das .obj-Ding?
Wie wende ich es auf das gesamte Projekt an? werden einzelne Dateien automatisch neu kompiliert?

Ich hoffe, dass die Kompilierungszeiten weiter optimiert werden können. C++-Code ohne Tricks fast sofort kompilieren zu können, wäre ein Glücksfall - nachdem ich gesehen habe, wie schnell Godot kompiliert, habe ich wirklich Mühe, zur unwirklichen Engine 4 zurückzukehren (kompilieren). , hat 45 Minuten gedauert, aber jetzt ist der Motor irgendwie aufgebläht, und es dauert bis zu 60 Minuten, was verdammt verrückt ist)

Ich denke, dass Godot das Potenzial hat, noch schneller zu kompilieren, und ich würde das Build-System selbst ersetzen, aber ich habe 0 Erfahrung, also hätte ich buchstäblich keine Ahnung, was ich tun soll

@Nosliwnayr
Können wir bitte vorkompilierte Header vermeiden? ich denke sie sind kompletter müll, halte es einfach

Sie machen auch das Teilen von Projekten viel ärgerlicher, und es ist einfach nie endend aufgebläht, mit zu vielen Nachteilen in meinem Kopf - aber hey, wenn jemand sie effektiv nutzt, bin ich cool, aber für mich erscheinen sie stattdessen wie ein schmutziger Trick einer echten Optimierung, und ich mag keine billigen Tricks um ehrlich zu sein

Nachdem ich die Unreal Engine 4 benutzt habe, bin ich müde von 20 GB vorkompiliertem Bullshit, ich denke einfach nicht, dass sie es wert sind, es muss ein weniger dummes System geben (die Unreal Engine 4, dauerte bis zu 60 - 80 GBs für mich, nicht cool)

Wenn Godot in diese Richtung geht, gehe ich davon aus, dass die Entwickler ihren gottverdammten Verstand verloren haben

zur Hölle, scheiß drauf, ich würde sie lieber bei Scons halten lassen, wenn es den Wahnsinnsball der irrealen Engine 4 vermeidet, denke ich, der klügere Ansatz wäre, Scons zu verbessern, anstatt sie direkt durch einen ganz neuen kaputten Arsch zu ersetzen Kompilierungssystem, wenn das aktuelle funktioniert... mehr oder weniger

Ich denke, der mentale Aufwand, der erforderlich ist, um ein brandneues System einzuführen, ist viel höher, als nur das zu verbessern, was wir bereits haben, und der neue Compiler könnte monatelang funktionsuntüchtig sein

Ich werde mich aber sicher nicht beschweren, wenn es fertig wird, aber bei einer so kritischen Motorkomponente muss man so ziemlich alles geben, es gibt kein Zurück mehr, wenn sich das ändert

@RaTcHeT302 - Die angegebene Befehlszeile ist, wenn Sie explizit nur ein einzelnes Ziel (in diesem Fall eine Objektdatei) kompilieren

In der Tat, wenn all die Leute, die sich über Probleme mit SCons beschweren, dazu beitragen würden, sie zu beheben, anstatt vorzuschlagen, ein kompliziertes Build-System auf ein neues, glänzenderes zu wechseln. Nun, viele dieser Bedenken wären behoben.

@bdbaddog Scons generiert keine Zwischenstufen-Build-Dateien. Es führt den Schritt "Projektabhängigkeit" im gleichen Schritt wie das Kompilieren aus, und sie können nicht getrennt werden.

Es ist, als würde man CMake sagen, dass es die Projektdateien jedes Mal generieren

Wenn ich die Git-Branches wechsle, kann ich Visual Studio nicht aktualisieren, ohne einen scons-Befehlszeilen-Build auszuführen, um die richtigen .vsproj- und .sln-Dateien zu regenerieren - und ich bereinige fast immer Build-Zweig-Änderungen, da ich in der Vergangenheit auf Probleme gestoßen bin.

Diese Zwischendateien sind nicht nur zum Erstellen gedacht, sondern können auch von statischen Analysatoren und anderen Projekten verwendet werden.

Obwohl ich zustimme, dass cmake nicht perfekt ist (ich mag es selbst nicht so sehr) und ich würde die Flexibilität von Python bevorzugen, bietet cmake die beste Integration und Unterstützung aller Build-Tools auf dem Tisch.

Beim Konvertieren meines Forks in CMake lag die meiste Komplexität in den Codegenerierungsdateien. Die Vorstellung, dass der Build kompliziert ist, ist ein Trugschluss. Der Build benötigt keine Scons, da er komplex ist. Es ist komplex, weil es Scons verwendet.

Vor diesem Hintergrund habe ich die Arbeit eingestellt, weil ich mich 2019 mit den leitenden Entwicklern der GDC (beim GitHub-Meetup) getroffen habe und sie sagten, sie hätten absolut nicht die Absicht, zu etwas Brauchbarerem zu wechseln, und zitierten, dass sie es vorziehen würden Der Build basiert vollständig auf Linux und tatsächlich verletzen sie die EULA, die Apple akzeptiert, um Build-Tools für das Cross-Kompilieren zu installieren.

Die Mentalität der Verantwortlichen lautet: "Der Zweck heiligt die Mittel" und es scheint keine Sorge zu geben, den Build als Software zu behandeln, sondern Godot behandelt ihn als eine Reihe von Skripten, die zufällig einen Build produzieren.

Ich werde die Änderungen, die ich an der Codegenerierung vorgenommen habe, nicht zu Godot beitragen (obwohl es besser lesbar und schneller ist), und ich habe diese Engine vollständig aufgegeben und mein Leben weitergeführt. Ich bin viel glücklicher, wenn ich ehrlich bin. Die Engine hat bereits erhebliche technische Schulden und ich sehe dies in etwa 3 Jahren als ein Problem, insbesondere da das C++-Standardkomitee an einem technischen Toolbericht arbeitet (ich bin daran beteiligt und habe auf Dinge wie die Standardisierung von Optionsdateien gedrängt bis zu einem gewissen Grad, aber es ist nur ein technischer Bericht, daher werden einige Leute davon abweichen).

Es ist auch eine Schande. Mein CMake-Build konnte eine Reihe von statischen Analysefehlern erkennen, die zu Tonnen von Problemen geführt haben und leicht lösbar sind, aber ich bin zu ausgebrannt, weil ich mit den Entwicklern auf der GDC darüber gestritten habe, um Fehler zu melden oder sogar zu versuchen, sie zu beheben Sie. Meine Energie und meine geistige Gesundheit sind woanders besser investiert.

Es gibt keine Welt, in der scons in der Lage sein wird, das kommende C++20-Moduldesign zu bewältigen, so sehr ich auch geschrien habe, wie es viele Tools zerstören wird. Es kann die Abhängigkeitsverfolgung dafür nicht verarbeiten und würde einen Vorscan-Schritt erfordern, der die Abhängigkeitsverfolgung noch weiter verlangsamt.

Schließlich schlage ich den Leuten vor, nicht zu versuchen, ein Tool zu verbessern, das nur geringfügige Änderungen akzeptieren kann. Scons bräuchte eine komplette Neufassung von Grund auf und eine große Anzahl von Breaking Changes, um die Verbesserungen zu erreichen, die die Leute hier suchen.

Ich schlage vor, dieses Thema zu schließen, da die Diskussion über die Änderung des Build-Systems auf der GDC 2019 beantwortet wurde, aber die Leads halten es nicht einmal für wert, ihre Zeit zu verschwenden, um dieses Thema zu kommentieren, was meiner Meinung nach zeigt, wie sehr ihnen die Ergonomie am Herzen liegt der Entwicklung.

Ich habe das Gefühl, wenn das bestehende Build-System zu 100% auf Plug-and-Play-Weise umgebaut würde, gäbe es keinen Grund von den Entwicklern, nicht zu wechseln.

Nur auf Linux zu bauen ist nutzlos. Eine Spiele-Engine zu haben, die nicht unter Windows läuft, wird ernsthafte Spieleentwickler abschrecken.

Ich möchte den Eindruck haben, dass sich die Spieleentwickler genug darum kümmern, das Build-System zu ändern, um die Benutzer zufrieden zu stellen.

Einer der Gründe, warum ich Unreal verlassen habe, ist, dass die Engine hauptsächlich auf die Erstellung von Blueprint/Front-End-Spielen zugeschnitten ist. Das Erstellen von Werkzeugen in C++-Modulen ist in Unreal äußerst mühsam und komplex.

Bisher war es in Godot recht angenehm. C++-Builds schneller zu machen, wäre ein großes Plus für die Community.

IIRC verwenden sie Wine, um die MSVC-Build-Tools auszuführen. Ändert immer noch nichts an Ihrem Standpunkt, und ich stimme zu.

Nur auf Linux zu bauen ist nutzlos. Eine Spiele-Engine zu haben, die nicht unter Windows läuft, wird ernsthafte Spieleentwickler abschrecken.

Godot war schon immer auf vielen Plattformen baubar, nicht nur auf Linux…

IIRC verwenden sie Wine, um die MSVC-Build-Tools auszuführen. Ändert immer noch nichts an Ihrem Standpunkt, und ich stimme zu.

Offizielle Windows-Builds werden mit MinGW kompiliert; Wir verwenden WINE nicht, um MSVC unter Linux auszuführen.

@marstaik - Wenn Sie Builds wechseln und Scons ausführen, nur um die MSVS-Projektdateien zu generieren, sollten Sie diese Dateien als Ziel angeben können und keinen vollständigen Build ausführen müssen.

also versuche:

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

SCons sollten dies tun können, ohne einen vollständigen Build durchzuführen, und es sollte auch korrekt ausgeführt werden, ohne dass Sie zuerst eine Bereinigung durchführen müssen.
(Übrigens. Ich bin der Projektbetreuer von SCons)

@bdbaddog Ich musste diesem Befehl vsproj=True hinzufügen, aber es scheint funktioniert zu haben

Von der Godot-src:
scons -j24 godot.vxcproj num_jobs=x vsproj=true

Bearbeiten: Aus irgendeinem Grund müssen Sie auch das Flag -j hinzufügen ...

@bdbaddog Ich musste diesem Befehl vsproj=True hinzufügen, aber es scheint funktioniert zu haben

Von der Godot-src:
scons -j24 godot.vxcproj num_jobs=x vsproj=true

Bearbeiten: Aus irgendeinem Grund müssen Sie auch das Flag -j hinzufügen ...

Viele dieser Flags sind keine Vanilla-SCons, sondern Teil der Art und Weise, wie verschiedene Pakete (in diesem Fall Godot) ihr Build-System mit SCons implementieren.
Schön, dass du einen Weg gefunden hast!

Warum SConstruct verwenden und darauf bestehen, nicht zu einem anderen Build-System zu wechseln?

@tjysdsg Die obige Diskussion fasst das sehr gut zusammen :slightly_smiling_face:

Ich schließe dies, weil wir im Laufe der Jahre klar gemacht haben, dass wir a priori nicht die Absicht haben, das Buildsystem zu ändern. Wir sind mit SCons zufrieden und alle Mängel können und sollten individuell bewertet werden, sowohl innerhalb unserer eigenen SCons-Nutzung als auch vorgelagert, wenn es auf das Tooling selbst zurückzuführen ist.

Der Umstieg auf ein "kühleres" Buildsystem wird nicht passieren. Die überwiegende Mehrheit der Mitwirkenden verwendet SCons gerne und es ist diejenige, die wir jetzt am besten kennen. Der Wechsel zu einem neuen Buildsystem ist mit Implementierungs- und Lernkosten verbunden, und es wurde bisher nicht bewiesen, dass diese die Mühe wert wären.

Alles in allem ist eine Änderung des Buildsystems nichts, was wir von neuen Mitwirkenden akzeptieren würden. Es muss von innen kommen, und alle Mitwirkenden müssen es als positive Veränderung sehen, damit es Sinn macht. Wir werden das Buildsystem nicht ändern, nur um neuen Benutzern zu gefallen, die versuchen, Godot aus dem Quellcode zu erstellen und es irgendwie nicht mögen, dass sie scons anstelle von cmake oder meson die sie gewöhnt sind. Wir werden auch keine Versuche akzeptieren, ein optionales neues Buildsystem einzuführen - aus Erfahrung weiß ich, dass dies nur zu Inkonsistenzen, Fehlern und Ausgabeunterschieden führen kann.

Natürlich sind wir offen dafür, unsere Meinung zu ändern, wenn klare Vorteile aufgelistet werden können (und mit einem funktionierenden Proof of Concept gezeigt werden), die die Kosten für die Änderung des Buildsystems überwiegen, aber ab heute und nach zwei Jahren der Diskussion hier tue ich es persönlich nicht den Anreiz nicht sehen.

@slurps-mad-rips hat es gut gesagt.

Es ist komplex, weil es Scons verwendet.

und

Mein CMake-Build konnte eine Reihe von statischen Analysefehlern erkennen, die zu Tonnen von Problemen geführt haben und leicht lösbar sind

Es ist ekelhaft, dass CMake nicht ernsthaft in Betracht gezogen wird. Ich kann mir viele Gründe vorstellen, SCons zu verwerfen, aber INSBESONDERE, dass CMake Fehler findet, die Scons nicht findet, macht es "lohnt", etwas anderes zu verwenden.

Der Umstieg auf ein "kühleres" Buildsystem wird nicht passieren

CMake ist nicht "cooler", sondern der Standard. Wenn Sie es tatsächlich verwendet haben, würden Sie sofort verstehen, warum.

Natürlich sind wir offen dafür, unsere Meinung zu ändern, wenn klare Vorteile aufgelistet (und mit einem funktionierenden Proof-of-Concept) nachgewiesen werden können, die die Kosten für die Änderung des Buildsystems überwiegen

Ich bin nicht davon überzeugt, dass jemand offen dafür ist, seine Meinung zu ändern. Auch hier zeigte @slurps-mad-rips deutliche Zuwächse und sie hat sogar die ganze Arbeit erledigt ...

Es ist beschämend, die offizielle Haltung des Godot-Teams zu vertreten, ihre Bemühungen, den Entwicklungsprozess zu verbessern, vollständig zu ignorieren.

Ich verstehe deinen Schmerz sehr gut, aber ich stimme immer noch mit anderen überein - der ganze Build
Systeme haben ihre
Vor- und Nachteile und im Allgemeinen gleich. Es gibt selten technische Gründe
um es zu ändern.
Aus politischen Gründen werden sie dir auf Dauer nichts nützen
Lauf. Alle
bevorzugt etwas anderes. Jedenfalls hindert niemand jemanden daran, Gabeln zu machen
für was auch immer
Gründe, also denke ich, dass dieser so gut ist wie jeder andere.

Am Freitag, den 21. Februar 2020 um 13:38 Uhr schrieb dorkbox [email protected] :

@slurps-mad-rips https://github.com/slurps-mad-rips hat es gut gesagt.

Es ist komplex, weil es Scons verwendet.

und

Mein CMake-Build konnte eine Reihe von statischen Analysefehlern abfangen, die
haben zu unzähligen Problemen geführt und sind leicht lösbar

Ich bin absolut ekelhaft, dass CMake nicht ernsthaft in Betracht gezogen wird, ich kann
Denken Sie an viele Gründe, SCons abzulegen, aber BESONDERS findet CMake
Fehler, die Scons nicht findet, macht es "lohnenswert", etwas anderes zu verwenden.

Der Umstieg auf ein "kühleres" Buildsystem wird nicht passieren

CMake ist nicht "cooler", sondern der Standard. Wenn du es tatsächlich benutzt hättest, würdest du es tun
sofort verstehen warum.

Natürlich sind wir offen dafür, unsere Meinung zu ändern, wenn klare Gewinne verzeichnet werden können
(und mit einem funktionierenden Proof of Concept belegt), die die Kosten für
das Buildsystem ändern

Ich bin nicht davon überzeugt, dass jemand offen dafür ist, seine Meinung zu ändern. Wieder,
@slurps-mad-rips https://github.com/slurps-mad-rips zeigte deutliche Gewinne,
und sie hat sogar die ganze Arbeit gemacht... Es ist schon getan.

Es ist beschämend, die offizielle Haltung des Godot-Teams zu repräsentieren,
ihre Bemühungen, den Entwicklungsprozess zu verbessern, völlig außer Acht lassen.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/godotengine/godot/issues/16014?email_source=notifications&email_token=AAABPU2PBIEK6PFKQ2LDTHLRD6VKVA5CNFSM4ENJ6NN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW59
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAABPU746R4YFHAI73Z57RTRD6VKVANCNFSM4ENJ6NNQ
.

@dorkbox - cmake hat statische Analysefehler gefunden? oder war es die Ausgabe der Kompilierungsdatenbank von cmake, die durch die statischen Analysetools von llvm ausgeführt wurde, die sie gefunden haben?

@bdbaddog , @slurps-mad-rips hat die Arbeit daran gemacht, und es wäre am besten, sie zu fragen. (Ich denke, es wäre die Ausgabe der statischen Analyse von llvm, aber ich bin nicht derjenige, der die Arbeit über cmake erstellt hat)

@slapin

Es gibt selten einen technischen Grund, es zu ändern.

Wie wäre es mit der Unterstützung von statischen Analysetools und modernen Sprachfeatures?

@bdbaddog @dorkbox Ich habe einfach clang- tidy aktiviert , um nach Dingen wie "Referenzen auf nicht statische Locals zurückgeben" und "Pufferüberläufe" über CMake zu suchen. Ich habe auch ein paar Dinge überprüft und ein paar weitere Ergebnisse erhalten. Ich konnte auch include-what-you-use zum Laufen bringen und es wurden einige unnötige Header-Einschlüsse gefunden.

Das heißt, ich habe den cmake-Port nicht wirklich "fertiggestellt". Der Teil, der nie portiert wurde, war die ganze Arbeit, die ich beim Versuch gemacht habe, die aktuellen Python-Skripte zu ändern, die einfach f.write für eine Datei aufrufen, um eine Datei aus JSON zu generieren. Ich konnte einen Großteil dieser Logik entfernen und durch einen generischen jinja2-basierten Vorlagengenerator ersetzen. Dies löste auch einen Hack, den der aktuelle Scons-Build unter Windows ausführt, wo er ein Skript als ausführbare Datei startet.

Ich hatte jedoch gehofft, mit dem Scons-Build gleich zu bleiben und zumindest meine Änderungen an der Codegenerierung einzubinden. Dies geschah nicht, weil sich die Python-Skripte, die zum Generieren von Quelldateien verwendet werden, ständig ändern und diese Änderungen synchron halten mit meinem jinja2-Templatisieren war eine Übung in Frustration.

Angesichts des sehr nachdrücklichen und harten Neins, das ich von den leitenden Entwicklern beim GDC GitHub-Meetup bekommen habe, habe ich beschlossen, dass ich nicht mehr zu Godot beitragen möchte. Meine Änderungen waren ungewollt, nicht erwünscht, und sie sind der Meinung anderer zu diesem Thema gleichgültig. Ich werde weder zu Godot beitragen, noch zu irgendwelchen Forks von Godot. Ich wünsche Ihnen allen viel Glück bei dem Versuch, die leitenden Entwickler von dieser Angelegenheit zu überzeugen, aber es ist wie ein Gespräch mit einer Ziegelmauer. Unnachgiebig, unbeweglich und apathisch gegenüber der Not aller in diesem Thread.

Wenn SCons also die Kompilierungsdatenbank ausspucken können, die in die llvm-Tools eingegeben wird, wäre dies auch von SCons aus möglich.

Wenn SCons also die Kompilierungsdatenbank ausspucken können, die in die llvm-Tools eingegeben wird, wäre dies auch von SCons aus möglich.

Es sieht so aus, als ob bei SCons der Sunk-Cost-Irrtum vor sich geht. Warum nicht etwas einfacheres, optimiertes und bereits Teil bestehender Build-Tools wie cmake verwenden?

Von der scons-Website:

Im Vergleich zu Scons ist CMake:

• Schneller
• Benötigt weniger Code für allgemeine Aufgaben
  
  
  
  • Wohl stabiler
  
  
  • Unterstützt die Ausgabe an Projekte wie Code::Blocks, Xcode usw., was Scons nicht tut
  
  

@dorkbox - Ich bin der Co-Manager des SCons-Projekts. Ich behalte nur die gewünschte Funktionalität im Auge.

Die letzten paar Releases und die bevorstehende haben Performance-Verbesserungen.

Darüber hinaus haben wir PRs für die Generierung von Ninja-Dateien und einige Community-Mitglieder haben Tools zur Kompilierung von Datenbanken. Daher werden einige der Probleme wahrscheinlich (zumindest teilweise, wenn nicht vollständig) in der nächsten Version behoben.

Mir sind keine Stabilitätsprobleme bekannt, die das Godot-Projekt betreffen und die wir nicht angesprochen haben. Wenn es noch offene Fragen gibt, teilen Sie uns dies bitte mit.
(Erreiche uns über: https://scons.org/contact.html)

Ich bin mir nicht sicher, ob cmake wirklich weniger Code für allgemeine Aufgaben benötigt, ich wäre an einem vernünftigen Vergleich interessiert.

Nun, was mich bei Scons am meisten ärgert, ist die Unfähigkeit, einfach alt zu werden
GNU make-Makefile. Mangel an Ninja - damit kann ich leben.
Auch Handhabung von Cross-Compile-Dienstprogrammen wie CMake-Toolchains und Autotools
Cross-Compiling-Fähigkeiten sind ein starker Schwachpunkt von cmake.
Der Rest ist in Ordnung, da ich kein IDE-Mitarbeiter bin. Meine IDE ist eine UNIX-Umgebung.

Am So, 23. Februar 2020 um 22:05 Uhr William Deegan [email protected]
schrieb:

@dorkbox https://github.com/dorkbox - Ich bin der Co-Manager des SCons-Projekts.
Ich behalte nur die gewünschte Funktionalität im Auge.

Die letzten paar Veröffentlichungen und die bevorstehende hatten Auftritte
Verbesserungen.

Außerdem haben wir PR's für die Generierung von Ninja-Dateien und etwas Community
Mitglieder verfügen über Tools zur Kompilierung von Datenbanken. Einige der Probleme sind also wahrscheinlich
(zumindest teilweise, wenn nicht vollständig) im nächsten Release behandelt werden.

Mir sind keine Stabilitätsprobleme bekannt, die das Godot-Projekt betreffen, das wir
nicht angesprochen. Wenn es noch offene Fragen gibt, teilen Sie uns dies bitte mit.
(Erreiche uns über: https://scons.org/contact.html)

Ich bin mir nicht sicher, ob cmake wirklich weniger Code für allgemeine Aufgaben benötigt
Interesse an einem vernünftigen Vergleich.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/godotengine/godot/issues/16014?email_source=notifications&email_token=AAABPU5TQQFET5RS2JDRY7TRELCHDA5CNFSM4ENJ6NN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXZLOKTODN5WWZissue59
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAABPU6UHPX3HJTWPAFTPATRELCHDANCNFSM4ENJ6NNQ
.