ZFX + Developia

Ich spiele seit langem mit dem Gedanken, den Compiler gemeinsam mit den Quelltexten in die Versionskontrolle einzuchecken. Vorteile:

• Entwickler müssen auf ihren Rechnern nicht selber Compiler installieren und pflegen. Insbesondere müssen Visual Studio-Versionen nicht miteinander abgestimmt werden.
• Ich kann auch in zehn Jahren noch die Version von vorgestern auschecken, und sie wird exakt so kompilieren und funktionieren wie an dem Tag, als sie eingecheckt wurde. (Viel Glück, heute eine bestimmte Version von Visual Studio 2008 zu finden!)
• Die Build-Skripte dürften etwas einfacher werden. Ich brauche zum Beispiel keine 10.000 Zeilen um herauszufinden, wo mein Visual Studio liegt.

Nachteile:

• Ich muss offensichtlich den Compiler pflegen. Zwar nun zentral statt bei jedem Entwickler einzeln, aber ich muss nach jedem Compiler-Update prüfen, dass alle Abhängigkeiten im Repo sind.
• Repo-Größe, offensichtlich. Bei Cross-Platform-Entwicklung mit Cross-Compilern habe ich schlimmstenfalls n×m Compiler im System, mit n die Anzahl der Zielplattformen (Win-x86, Win-x64, MacOS-x64, …) und m Anzahl der Entwicklerplattformen (Win-x64, MacOS).

Gedanken? Hängt wohl eng mit der Frage zusammen, ob man SDKs einchecken sollte.

Wir machen das schon über 30 Jahre so und ich käme gar nicht auf die Idee, es so NICHT zu tun.
Die Wartung hat man so oder so, oder wie macht ihr die Nightlybuilds bzw die Wartung dieser Kisten (bei uns VMs)?
Bei uns gibt es eine "build" Repo. Die wird identisch versioniert (gebrancht/getagt) wie die anderen Repos.
Darin wird dann nach Architektur unterteilt, win64, darwin, darwin-arm, unix (shared Scripts), ubuntu, sles.
Die VMs wo bei uns Builden nennen wir "Slaves". Davon gibt es N pro Version und können automatisiert erzeugt werden.
Es gibt pro Version ein Master. Der prüft in welcher Reihenfolge die Projekte gebuildet werden müssen und
welche parallel gebuildet werden können. Die Slaves werden vorbereitet (ggf neue Slaves erzeugt) und
dann wird die Arbeit auf die Slaves verteilt. Das läuft alles via Jenkins. Benötigt natürlich
Zeit sowas aufzusetzen und zu pflegen, wir haben aber alleine im Buildteam 3 Leute wo sich damit befassen.
Das Endresultat wird wiederum in ein anderes Repo ("gen") eingecheckt. Bei diesen Repos (gen/build) tun wir ab und an (idR 1mal im Jahr)
die History nuken einfach wegen dem Diskspace. Releases (inkl Buildsymbole, Sources etc) werden dann in einem separaten
Repo archiviert und Backups von dem lagern wir auch in einem Bankschliessfach.
Der Vorteil von separaten Repos ist dass man sie falls nötig auf unterschiedlichen Servern betreiben kann.
In grossen Monorepos sollten ausschliesslich Sourcesfiles liegen.
Es gab schon Diskussionen ob zB. das Endresultat lieber in eine Artifaktrepo (zB. Nexus)
kommen sollten statt ins VCS. Mit dem Resultat dass es keinen Vorteil gibt.
Wir bleiben bei dem separaten "gen" und "build" Repo und löschen da ab und an die History.
(Soweit ich weiss wird dazu der aktuelle Stand wegkopiert, das Repo gelöscht + neu angelegt und der letzter Stand initial importiert.)

Ich kann das Leid, dass hinter dieser Idee steht, sehr gut nachvollziehen... Ein paar Gedanken dazu:
- Wie garantiert man, dass der Compiler selber in 10 oder 20 Jahren noch läuft?
- Ist das mit aktuellen Tools überhaupt realisierbar oder müssten ganz neue, packbare Umgebungen geschaffen werden?

Insgesamt habe ich für C++ die Hoffnung längst aufgegeben. Irgendwo ist einfach die Tatsache, dass Build-Skripte benötigt werden ein Armutszeugnis. Gefühlt braucht man in Python z.B. nur eine Liste mit Abhängigkeiten und ihren Versionen, die gibt man einem Paketmanager und dann läuft das alles. In C++ hingegen... Ich meine, es gibt ja durchaus Paketmanager für C++, aber die scheinen mir noch nicht etabliert genug um wirklich zukunftssicher zu sein. Am ehesten ist noch CMake ein Standard, aber das ist auch einfach komplett kaputt und funktioniert hinten und vorne überhaupt nicht.

Wenn man den Compiler einchecken will, bedingt das ja auch, sämtliche Abhängigkeiten einzuchecken (behaupte ich einfach mal, der Compiler erscheint mir der schwierigste Teil zu sein, und demnach vermutlich das letzte, was man bündeln will). Und mein Lib Verzeichnis hat halt auch irgendwie über 20 GB und über 200k Dateien. Nicht alles wird für alles benötigt, aber für ein größeres Projekt kommt da schon eine ganze Menge zusammen.

Letztendlich könnte man dann auch fast den Weg gehen und einfach das komplette System in eine Virtual Machine zu packen. Aber irgendwie erscheint mir da die ansicht, dass Code verderbliche Ware ist und nach ein paar Jahren einfach unbrauchbar wird, wenn man ihn nicht ständig auf neue Gegebenheiten anpasst, realistischer zu sein. Das mag deprimierend sein, aber damit muss man vielleicht leben. Und ehrlich gesagt, wenn man ein altes Spiel für ein neues System kompilieren will und dafür dann das Sprite-Rendering von DX 5 auf irgendwas moderne umstellt, dann läuft es letztendlich im Zweifelsfalle nachher auch einfach besser, ohne das sich am Spielgefühl irgendetwas ändert.

Jonathan hat geschrieben: ↑13.02.2021, 13:32 Letztendlich könnte man dann auch fast den Weg gehen und einfach das komplette System in eine Virtual Machine zu packen.

Ist das nicht Docker?

Bei meinen privaten Projekten sind die Tools im Repository (z.B. Ninja, Premake und Nasm). Der Hauptgrund dafür ist, es für andere Leute einfacher zu machen, den Code zu kompilieren. Bei einigen Open Source Projekten gibt es ja eine ganze Anleitung oder sogar Handbuch, was man denn alles eingerichten soll, bevor man den Code kompilieren darf. Das reicht ja von irgendwelchen Bibliotheken bis eben auch Build-Tools usw. usf. Den Compiler hab ich aber noch nicht im Repository. Die Gründe dafür sind:

• Der Compiler ist riesig. Die anderen Progrämmchen belaufen sich für Linux und Windows auf insgesamt nur 10 MB. Die Clang-Binary nur für Windows selbst hat bereits 90 MB und das beinhaltet noch nicht alle DLLs oder die Includes.
• Beim Microsoft-Compiler weiß ich gar nicht, ob das möglich ist. Ich würde fast tippen, dass er unglaublich viele Dinge aus der Registry ausließt und es einige Mühe kostet, ihn portabel zu verwenden.
• Compiler sind relativ kurzlebig. Eine Ninja- oder Nasm-Version von 2015 benutzen ist eig. kein Problem, aber eine 5 Jahre alte Compiler-Version würde ich nicht verwenden. Es würde gar nicht erst kompilieren, weil einige Sprach-Features fehlen und eine Menge Bugs noch nicht behoben sind.
• Es gibt eigentlich keinen der C++ entwickelt und nicht einen Compiler verfügbar hat. Es gibt viele Leute die kein Premake oder Ninja verwenden, aber einen Compiler haben sie alle. Dadurch entfällt das Komfort-Argument teilweise.
• Wenn der Code nur mit manchen Compilern funktioniert, lohnt es sich ohnehin oft den Code zu fixen.

Der meiner Meinung nach problematischte Punkt ist halt wirklich der erste. Wenn dann würde ich es auch in einen eigenen Branch oder so packen, damit mit tausend sich ständig erneuernden Compilern die Versionsgeschichte nicht explodiert.

Jonathan hat geschrieben: ↑13.02.2021, 13:32 - Wie garantiert man, dass der Compiler selber in 10 oder 20 Jahren noch läuft?

Ich denke, garantieren kann man das nicht. Allerdings schätze ich die Chance eigentlich ganz gut an. Compiler sind zwar riesige Programme, aber sie interagieren nur minimal mit dem Betriebssystem. Ausgabe schreiben. Dateien öffnen und schließen. Ich denke die Chancen sind schon ziemlich gut, dass diese Funktionen erhalten bleiben. Bei Windows schon gleich doppelt, denn was ändert sich da schon? Bei mir funktionieren die meisten Windows 95 Programme noch bestens. Ich habe allerdings gerade leider keinen alten Compiler zur Hand, um die genaue These zu testen. :D

Jonathan hat geschrieben: ↑13.02.2021, 13:32 - Ist das mit aktuellen Tools überhaupt realisierbar oder müssten ganz neue, packbare Umgebungen geschaffen werden?

Das könnte schwierig werden. Ich glaube, ich habe GCC und Clang schonmal portabel verwendet, aber nicht Microsoft VC++. Einige kurze Internet-Suche ergab hier nichts.

Eine Möglichkeit wäre auch den C/C++-Modus des Zig-Compilers zu verwenden. Da sind jedenfalls alle möglichen Umgebungen für den Clang-Compiler plus System-Abhängigkeiten portabel auf ~100 MB komprimiert drin. Sogar mit Cross-Compilation und inklusive FreeBSD- und MacOS-Unterstützung, GNU-Libc und Musl-Libc in allen möglichen Versionen usw. Der einzige Haken, den ich feststellen konnte, als ich das mal ausprobiert habe: Die Windows-Header sind dort so eingestellt, dass sie nur mit Windows 10 ab Windows 8.1 funktionieren. Das ist natürlich extrem realitätsfern. Ich hab es dann durch eine kleine Korrektur in irgendeinen Header mit älterem Windows zum Laufen gebracht, aber es könnte sein, dass dies in Zukunft schwieriger wird.

Meiner Meinung nach ist es total bescheuert, wie unportabel so viel Software ist. Ich kann jeden verstehen der Docker verwendet, aber es ist trotzdem ein Armutszeugnis, dass man soetwas überhaupt braucht. Warum kann man nicht alle Software wie Zig verwenden mit nur minimaler und transparenter systemweiter Konfiguration? Besonders schlimm finde ich das bei Linux, wo standardmäßig bei fast allen Distributationen alle Programme nach Dateityp in lib/bin/usw. Ordner aufgeteilt werden und dann komplett vermischt vorliegen.

Ich kenne die Strategie so ähnlich von einem Schwesterunternehmen. Dort liegen die Tools in einem separaten Repository.
Man möchte sie für mehrere Projekte verwenden. Mit git submodules könnte man z.B. noch eine Verbindung zwischen den Repos herstellen wenn man wollte. Es handelt sich dabei aber auch um eine GCC basierende Toolchain, was die Sache wohl einfacher macht als mit MSVC, Visual Studio etc.

Für Microsoft Tools hab ich nur mit der VM Lösung Erfahrung. Da hab ich manchmal mit einer VS2005 Installation zu tun. Das kann man natürlich nur zu Konservierungszwecken machen wenn man ein Produkt abgekündigt. Als Produktivsystem sehe ich soetwas nicht.

Ich finde es, wenn ich das so lese, ein bisschen faszinierend, dass es in einem Paralelluniversum ein Tool gibt, das mir zumindest verspricht, mir alle diese Sorgen abzunehmen (npm) und einen Konzern (AWS) der mir erlaubt beliebigen Code für roundabout schmale $10 per million Requests in eine globale Infrastruktur hochzuladen, für die (also vergleichbar den Teil den ich nutze) ich vor 10 Jahren größenordnungsmäßig $10K im Monat gezahlt hätte.

Und natürlich geht das nicht für jeden Anwendungsfall und natürlich können wir jetzt den ganzen Tag gemeinsam über die paar berühmten major npm Fuckups lachen und natürlich ist Platform-Lockin real und die Cloud nur somebody else's Computer. Alles geschenkt.

Ändert aber meiner Meinung nach nichts daran, wie krass die moderne IT bifurkiert ist und welcher Level an Komfort (um einen Preis natürlich) technisch möglich ist und wie weit manche Ökosysteme (die natürlich ihre eigenen Vorteile haben) davon weg sind.

Vielleicht bin ich naiv, oder geblendet von den Möglichkeiten, oder es ist Stockholm Syndrom, aber oben war von 10 Jahren die Rede. For whatever it is worth, AWS supportet nach 7 Jahren (also "fast 10") noch Java 8 (unter dem Namen Corretto). Oracle (ex Sun) nicht mehr.

Keine Ahnung wie das bei npm ist, aber bei Gradle checkt man nur eine Batch-/Shell-Datei und eine Mikro-JAR ein, und das Zeug lädt dann anhand einer Version in der Konfiguration Gradle runter. Da ist tatsächlich die JVM die offene Flanke. Da könnte man aber das gleiche machen. Wenn ich so darüber nachdenke ist nodejs wohl mit der JVM vergleichbar... Also hat man bei npm nodejs gleich mehr Tooling dabei und es ist an der Stelle schon irgendwie überlegen. Auf der anderen Seite finde ich die Trennung zwischen VM und Build-Tool eigentlich ganz gut.

Ich finde es spannend, dass da bei C++ scheinbar die Zeit stehen geblieben ist. So kommt es mir jedenfalls vor. Vielleicht liegt es auch daran, dass unter Linux das ganze mit dem OS-Paket-Manager verquickt ist und man sich nicht die Mühe macht da was eigenes auf die Beine zu stellen. Rust ist ja sicher auch unter anderem deshalb so eingeschlagen, weil Cargo gut funktioniert.

Das ganze Prinzip findet seinen Höhepunkt ja irgendwie in Docker Images, die auch die IDE hochziehen. https://www.gitpod.io/ finde ich da schon eindrucksvoll. @Krishty ich glaube das würde ich fast an Deiner Stelle mal ausprobieren. https://devblogs.microsoft.com/cppblog/ ... -projects/ Die Artefakte werden eigentlich nicht so einfach wegradiert aus den Repositories, dann musst Du das nicht selbst pflegen. Allerdings weiß ich nicht wie hoch der Overhead da ist.

Chromanoid hat geschrieben: ↑13.02.2021, 18:40 Keine Ahnung wie das bei npm ist, aber bei Gradle checkt man nur eine Batch-/Shell-Datei und eine Mikro-JAR ein, und das Zeug lädt dann anhand einer Version in der Konfiguration Gradle runter. Da ist tatsächlich die JVM die offene Flanke. Da könnte man aber das gleiche machen. Wenn ich so darüber nachdenke ist nodejs wohl mit der JVM vergleichbar... Also hat man bei npm gleich mehr Tooling dabei und es ist an der Stelle schon irgendwie überlegen. Auf der anderen Seite finde ich die Trennung zwischen VM und Build-Tool eigentlich ganz gut.

Naja, den Unterschied zwischen Runtime (node) und Paketverwaltung (npm) habe ich schon auch. Nur dass ich die Runtime halt zusammen mit der Infrastruktur bei AWS miete.

Ääh, ja ich meinte dass man bei nodejs npm meist gleich dabei hat. D.h. wenn man jetzt lokal entwickelt, muss man sich "nur" nodejs ziehen. Bei Gradle muss man halt ne JVM ziehen und den Rest macht der Gradle Wrapper (auch ohne vorherige Gradle-Installation) - übrigens wenn man will auch NodeJS und NPM :D. Aber da ist ja NPM wahrscheinlich noch umfangreicher - zumindest kann man Gradle auch von NPM starten ^^

Woah, danke für das reichliche Feedback!

mrz hat geschrieben: ↑13.02.2021, 13:18Wir machen das schon über 30 Jahre so und ich käme gar nicht auf die Idee, es so NICHT zu tun. Die Wartung hat man so oder so, oder wie macht ihr die Nightlybuilds bzw die Wartung dieser Kisten (bei uns VMs)?

Wir sind hier höchtens zu dritt, haben also nicht einmal ein eigenes Build Team :) Entsprechend auch keine Nightlys oder so. Bisher kommt man damit aus, dass sich jeder Visual Studio installiert und es selber pflegt.

Jonathan hat geschrieben: ↑13.02.2021, 13:32- Ist das mit aktuellen Tools überhaupt realisierbar oder müssten ganz neue, packbare Umgebungen geschaffen werden?

Spiele Programmierer hat geschrieben: ↑13.02.2021, 15:03Das könnte schwierig werden. Ich glaube, ich habe GCC und Clang schonmal portabel verwendet, aber nicht Microsoft VC++. Einige kurze Internet-Suche ergab hier nichts.

Vor zehn Jahren konnte ich Visual C++ portabel verwenden, weil es im Windows SDK enthalten war. Dann ist es in die Visual C++ Build Tools gewandert. Die Downloads scheinen nun tot zu sein; es gibt wohl nur noch ein Chocolatey Package: https://chocolatey.org/packages/visuals ... buildtools
Da steht mir also ein Wochenende Ausprobiererei bevor …

Spiele Programmierer hat geschrieben: ↑13.02.2021, 15:03Eine Möglichkeit wäre auch den C/C++-Modus des Zig-Compilers zu verwenden. […] Der einzige Haken, den ich feststellen konnte, als ich das mal ausprobiert habe: Die Windows-Header sind dort so eingestellt, dass sie nur mit Windows 10 ab Windows 8.1 funktionieren. Das ist natürlich extrem realitätsfern.

Cool. Windows-Header benutze ich nicht, von daher kein Problem.

nullptr hat geschrieben: ↑13.02.2021, 16:32Ich kenne die Strategie so ähnlich von einem Schwesterunternehmen. Dort liegen die Tools in einem separaten Repository.
Man möchte sie für mehrere Projekte verwenden. Mit git submodules könnte man z.B. noch eine Verbindung zwischen den Repos herstellen wenn man wollte.

Das war mir tatsächlich entfallen: Natürlich möchte ich die Toolchain nicht unbedingt für jedes kleine Projekt von Null aufziehen, warten, und einchecken. Ich habe letztes Jahr mit git-Submodules gearbeitet (wollte mein Framework mal im git von allem trennen), musste das aber mangels Unterstützung durch Visual Studio wieder einstampfen. Also wieder ein TODO: git-Submodule-Unterstützung in VS testen, und entsprechend planen …

Alexander Kornrumpf hat geschrieben: ↑13.02.2021, 13:48

Jonathan hat geschrieben: ↑13.02.2021, 13:32Letztendlich könnte man dann auch fast den Weg gehen und einfach das komplette System in eine Virtual Machine zu packen.

Ist das nicht Docker?

Wenn man das hier weiterspinnt, kommt man zwangsläufig da an. Ob die Abhängigkeiten damit aufhören, weiß ich nicht – VMs laufen ja auch nicht von alleine – aber ich weiß aus dem Day Job, was es bedeutet, für ein Produkt auch noch das Betriebssystem zu pflegen, und sowas möchte ich um keinen Preis an der Hacke haben. Ich weiß gerade echt nicht, wo ich die Grenze ziehen soll (nur Code, Code + SDKs, Code + SDKs + Compiler, Code + SDKs + Compiler + OS). Hm.

Die vc++ build tools gibts nur noch als chocolatey Paket? Oder meinst du in portabler Fassung? Im Grunde ist hier eine Anleitung wie man sich einen setup Script baut: https://docs.microsoft.com/en-us/visual ... ew=vs-2019 keine Ahnung ob es da nen trick für portable Nutzung gibt...

Bzgl. Module und Verteilung, das hier schon mal gesehen? https://github.com/microsoft/vcpkg

Ich weiß gerade echt nicht, wo ich die Grenze ziehen soll (nur Code, Code + SDKs, Code + SDKs + Compiler, Code + SDKs + Compiler + OS). Hm.

Was ist denn für alle Beteiligten der geringste Aufwand? Ihr seid ja nur zu Dritt wie du sagst.

Ich würde die Grenze da ziehen wo du wirklich einen Mehrwert erwarten kannst. Wenn du einen Monat beschäftigt bist das umzubauen, dann noch jede Woche drei Stunden mit der Pflege des Systems beschäftigt bist, um nachher 3 Sekunden Geklicke einzusparen, dann hast du nichts gekonnt.

Um das rauszufinden musst du das natürlich erst mal durchtesten, einmal die Zeit investieren. Der berühmte Prototyp. Und da würde ich mir dann auch mal die Meinung deiner Mitbenutzer einholen.

Und du musst da auch an die Zukunft und die Toolchain denken. Selbst das einfachste Script braucht ab und zu Wartung. Und gemein wird es da wo du ein Script von einem Vorgänger übernimmst von dem du nicht weisst was es eigentlich tut. Und selbiges dann den Dienst quittert. Ist mir mit Github Actions passiert. Ich komme immer noch nicht dahinter was ich falsch mache. Und der der mir das eingerichtet hat hat grade keine Zeit sich drum zu kümmern.

Mich beissen die ganzen Tools im Blender Source Code immer wieder tierisch in den Allerwertesten. Genauso diese verdammten Submodule. Die hängen ja an Blender. Also mussten wir das wieder ausbauen damit unsere Sachen da drin bleiben, und uns nicht die Blender Submodule Updates ständig alles zertrümmern. Und haben nun trotzdem ständig Ärger damit.

Bezüglich Toolchain. Die haben in Blender zum Beispiel mehrere Scripte eingebaut das dir automatisch aus einem Iconsheet in einer SVG Datei die ganzen Icons generiert. Mit dem Ergebnis dass du das SVN File benutzen MUSST um Icons zu bauen. Sprich ich habe meine Icons eigentlich fertig als PNG, muss die aber erst mal in ein Vectorformat umwandeln und in das SVG einbauen, damit das dann im Buildprozess in PNG zurückgewandelt wird um dann endlich als dat File abgespeichert zu werden. Das ist tierisch limitierend und nervig. Denn das SVG Iconsheet ist inzwischen so gross dass es kaum noch zu handeln ist. Inkscape braucht ewig zum laden, und kommt an seine Performancegrenze. Und sehr geil: die neueste Version von Inkscape kann ich nicht verwenden weil ein paar Last Minute Änderungen in Version 1 den ganzen Buildprozess durcheinanderwirbelt. Ich hänge jetzt auf Inkscape Version 0.9x fest. Keine Ahnung wie das die Blender Devs hinbekommen, die haben das Script einfach auf Version 1.0 umgeschrieben. Ich habe aber seitdem auch keine neuen Icons in Blender gesehn. Vielleicht wissen die noch gar nichts von ihrem Glück ^^

Und mit Blender 2.80 haben sie da noch eins drauf gesetzt. Nun muss man die Icons für die Toolbar erst mal in 3D modeln. Weil das Script ein blend file mit den 3D Modellen erwartet. Einmal mit Profis halt.

Und ich finde einfach nicht raus wie man ein einfaches dat schreibt und diese irrsinnige Nerd Pipeline umgeht. Weil das alles über zig Files läuft, mit sogenanntem selbsterklärenden Code und so, zigfach verwoben mit dem Core Code, in Cmakefiles verewigt und in den Build Prozess mit eingebaut. Wieso auch immer sie die schon erstellten dat files unter Linux noch mal überschreiben zu meinen müssen, und unter Windows nicht ...

Sorry fürs abschweifen. Trotzdem, think twice ob du da wirklich Tools mit reinbauen willst. Nicht alles was machbar ist ist auch sinnvoll. Jedes zusätzliche Modul verkompliziert die Lage. Und Abhängigkeiten machen vor allem eins: abhängig. Und manchmal ist Handarbeit zwar nervig, aber unter dem Strich die bessere und schnellere Lösung. Hatten wir da nicht unlängst so ein Beispiel im Jammer Thread? Irgendjemand hatte mir geraten ein Script für einen Job zu schreiben, was mich locker nen Tag beschäftigt hätte, mit nach oben offenem Ende. Und von Hand war das in einer halben Stunde gelöst. Ohne Script. Klar, nervig. Aber schneller.

Die Tools mit einzubauen kann eine Verbesserung sein, muss aber nicht. Das kommt immer auf den Einzelfall an. Du kannst zwar einerseits Zeit und Energie einsparen. Aber du kannst dir deine Pipeline mit sowas auch herrlichst verkomplizieren wenn du die Konsequenzen nicht komplett durchdacht hast. Und je mehr du da reinballerst, um so schwerer ist das dann wieder zu trennen falls es doch eine Verschlimmerung der Pipeline ist statt eine Verbesserung.

Meine fünf Gedanken dazu :)

@Tiles Stimme Dir da zu. Ich finde halt an Automatisierung die implizite Dokumentation des Vorgangs gut. Das ist bei komplizierteren Sachen oft ganz gut, selbst wenn es sich zeitlich nicht unbedingt lohnt. So sollte es natürlich nicht sein :)

Ja. Das knifflige ist halt echt einschätzen zu können ob sich der ganze Aufwand nachher rechnet :)

Tiles hat geschrieben: ↑14.02.2021, 08:34Ich würde die Grenze da ziehen wo du wirklich einen Mehrwert erwarten kannst. Wenn du einen Monat beschäftigt bist das umzubauen, dann noch jede Woche drei Stunden mit der Pflege des Systems beschäftigt bist, um nachher 3 Sekunden Geklicke einzusparen, dann hast du nichts gekonnt.

Tjoa, ist halt schwer einzuschätzen.

Aktuell versuche ich ein Package für den Microsoft Store zu bauen. Auf einem PC funktioniert es, auf dem anderen nicht. Auf beiden sind identische Visual Studios installiert. Oder nicht? Wie kriege ich das raus?

Wenn ich den Fehler finde, und er hat nichts mit unterschiedlicher Software auf den Systemen zu tun – hätte es mir dann zumindest Zeit gespart wenn alle Tools aus dem Repository gekommen wären und ich unterschiedliche Konfigurationen von Anfang an hätte ausschließen können? Oder hätte ich wirklich nur, wie du sagst, 30 Sekunden Klicken gespart? Schwer berechenbar :(

Ich kenne es eigentlich so dass alte Compiler (oder alte Buildserver wenn es schon fortschrittlicher ist) einfach in eine VM gepackt werden.
Eine pragmatische Lösung für so ein kleines Team wäre z.B. vor einen Umstieg auf eine neue Majorversion von VS eine Entwickler VM wegzusichern.

Krishty hat geschrieben: ↑13.02.2021, 21:01

Jonathan hat geschrieben: ↑13.02.2021, 13:32- Ist das mit aktuellen Tools überhaupt realisierbar oder müssten ganz neue, packbare Umgebungen geschaffen werden?

Spiele Programmierer hat geschrieben: ↑13.02.2021, 15:03Das könnte schwierig werden. Ich glaube, ich habe GCC und Clang schonmal portabel verwendet, aber nicht Microsoft VC++. Einige kurze Internet-Suche ergab hier nichts.

Vor zehn Jahren konnte ich Visual C++ portabel verwenden, weil es im Windows SDK enthalten war. Dann ist es in die Visual C++ Build Tools gewandert. Die Downloads scheinen nun tot zu sein; es gibt wohl nur noch ein Chocolatey Package: https://chocolatey.org/packages/visuals ... buildtools
Da steht mir also ein Wochenende Ausprobiererei bevor …

Nur ein erster kurzer Test, aber: Man kann bei VS das Compiler-Verzeichnis einfach kopieren und cl.exe bzw. link.exe problemlos aufrufen. Wenn man PGO & Co. weglässt, hat man ein paar Dateien mit zusammen ~25 MiB Größe – ein Viertel der Clang-Executable.

MSBuild scheint das größere Problem zu werden. Das ist komplett auf .NET gebaut, benötigt also das .NET-Framework und die .NET-Runtime.

Kurzes Update bis ich dazu komme, was Ausführliches zu schreiben:

1. Ich konnte mir ein portables Visual-C++-Toolset zusammenstellen aus C++-Compiler, Resource-Compiler, Shader-Compiler, und Linker. Das habe ich in mein Repo eingecheckt. Damit kann ich auf jedem Rechner kompilieren – ganz ohne Visual Studio; sogar ohne installierte Visual-C++-Runtime. (Natürlich nur Befehlszeile, nicht IDE!)
    
2. Das funktioniert nur mit dem Toolset, das nativ zum System ist. Ich kann bspw. nicht das 32-Bit-Toolset auf meinem 64-Bit-Rechner nutzen. Grund sind üble Differenzen in den Umgebungsvariablen und der DLL-Suchpfade.
    
3. Clang ist sowieso sehr einfach portabel einsetzbar.
    
4. Clang ist 100 MiB groß, weil immer alle Cross-Compile-Zielarchitekturen reinkompiliert sind. Wenn man also von einem 64-Bit-PC kompilieren möchte für x86-32 + x86-64 + ARM, dann braucht man nur die 64-Bit-Version von Clang und dem LLVM-Linker (gemeinsam rund 200 MiB). Visual Studio bietet dagegen drei unterschiedliche Sätze Executables (eine pro Zielarchitektur) von jeweils ~25 MiB Größe.
    
5. Clang für Windows hat keine eigene C++-Runtime. Es geht nur Microsofts. Geht so weit, dass Clang in der Registry nach installiertem Visual Studio sucht und sich von dort die C++-Runtime holt.
    
6. Clang für Windows mimt 1:1 Microsofts Linker. Es scheint absolut unmöglich zu sein, den LLVM-Linker auf Windows mit der nativen Befehlszeile zu nutzen oder ihn andere Tools als die aus Microsofts Windows SDK nutzen zu lassen.
    
7. Microsofts C++-Runtime ist eine Abhängigkeitshölle. Die eine Hälfte der #includes liegt in der Visual Studio-Installation. Die andere Hälfte wird seit Windows 8 vom Betriebssystem gestellt, und liegt deshalb im Windows SDK. Die Abhängigkeiten und Querabhängigkeiten sind ein Fest.
    
8. MSBuild ist kein Problem mehr, da ich in völlig wahnwitziger und für mich typischer Kopf-durch-die-Wand-Aktion auf Ninja (handgeschrieben) umgestiegen bin.

Mir wird also gerade klar, dass Clang auf Windows nur ein möglichst Bug-für-Bug-kompatibler Visual-C++-Abklatsch ist und keine Alternative. (Einzige Daseinsberechtigung scheint es zu sein, die Chrome-Quelltexte auf Windows linken zu können, ohne das existierende Build-System anpacken zu müssen.) Ich hätte von Anfang an MinGW nutzen sollen; das bringt sein eigenes Ökosystem mit.

Das Git-Repo auf beliebige PCs zu kopieren und dann mal schnell ein paar Dutzend Projekte mit Visual C++ und Clang durchzukompilieren ist geil.

Habe ein Statement von Microsoft gefunden, dass es rechtlich nicht erlaubt ist, den Compiler einzuchecken und auf anderen PCs auszuchecken.

War eigentlich klar, aber als Referenz sei es hier wiederholt.

https://developercommunity.visualstudio.com/t/allow-redistribution-of-the-clexe-compiler/975508 hat geschrieben:- cl.exe is available only by installing Visual Studio or Visual Studio Build Tools (the latter is primarily for CI/CD environments)

- the VS license does not allow redistribution of binaries unless explicitly stated in the license (e.g. VCRedist has a license that allows redistribution, but cl.exe doesn't)

- the minimum installation required to get cl.exe is by customizing the Visual Studio installer options and installing a subset of the C++ Desktop workload or the C++ Gaming workload - this will in turn install several other build tools e.g. headers/static libs/link.exe/IDE components/etc. that strictly speaking for you game engine might not be needed, but...

- this will also allow your game developer customers access to the Visual Studio edit/build/debug inner-loop that I am going to assume it is desirable in your game development scenarios

„Minimum Workload“ of 3 GiB, LOL

For the record: Was man braucht, um Compiler und Linker nutzen zu können, sind ohne jede Kompression rund 80 MiB. Also noch weniger als Clang.exe.

Also muss im Repository ein Installer drin sein der das Tool beim Ausführen des Builds herunter lädt oder?

Ja, was die Sache natürlich ad absurdum führt – jetzt kannst du nicht mehr die Version von vor drei Monaten auschecken weil a) schon eine neuere auf deinem System installiert wurde und b) Microsoft den Download gelöscht hat.

Erzähler: Krishty würde es einfach trotzdem so machen, wie er es für richtig hält.

Ah stimmt, diese beknackten Tools sind ja nie "portabel". Ich glaube bei Linux ist das auch immer so doof. Ich habe aktuell immer wieder mit NPM zu tun, da wollen auch immer alle Tools, dass man sie global installiert in ihren Anleitungen. "Nein, ich will reproducible Builds mit ephemeral Build-Environments, die ich nicht händisch zusammenbasteln muss, und ja, ich will auch unterschiedliche Versionen von Tools auf der gleichen Maschine benutzen können."

Der Workaround sind ja Docker-Images, die alle nötigen Tools installiert haben, weil die Tools immer systemweite Auswirkungen haben. Hatten wir ja oben schon geschrieben.

Apropos Linux und Builds: How Uber Uses Zig. Das finde ich schon ziemlich bemerkenswert. Die nehmen von Zig die Build-Tools, weil: Main selling points of C/C++ toolchain on top of zig-cc over the alternatives: configurable versions of glibc and macOS cross-compilation. Völlig gaga, dass die Toolchains da so nervig sind, dass die solche Wege gehen. Nichts gegen Zig, aber für einen vernünftigen Build sollte man nicht so weit gehen müssen.

Chromanoid hat geschrieben: ↑14.07.2022, 10:55 Apropos Linux und Builds: How Uber Uses Zig. Das finde ich schon ziemlich bemerkenswert. Die nehmen von Zig die Build-Tools, weil: Main selling points of C/C++ toolchain on top of zig-cc over the alternatives: configurable versions of glibc and macOS cross-compilation. Völlig gaga, dass die Toolchains da so nervig sind, dass die solche Wege gehen. Nichts gegen Zig, aber für einen vernünftigen Build sollte man nicht so weit gehen müssen.

Das geilste ist ja, dass die Zig-Installation ein einzelnes Archiv ist, enthält eine Executable sowie Source Files für die mitgelieferten Libs. Perfekt archivierbar durch Copy-Paste. Passt ja auch zum Thema :)