Allgemein
Krypton build system fokussiert sich auf C++, Paket- und Abhängigkeiten-Verwaltung.
Es bietet auch die Möglichkeit Projekte zu bauen und setzt auf Beschreibung des Ziels, statt Bauvorschriften, wie bei den üblichen Tools.

Krypton parsed sämtlichen C++ Code im Projekt und erkennt, ob es eine Statische/Dynamische Bibliothekt oder executable ist und soll künftig möglichst viele Build Settings bereits durch die Codeanalyse erkennen und den Konfigurationsaufand möglichst gering halten. Beschreibt die Konfiguration ein anderen Zustand, dann wird dieser überschreiben aber sonnst als Fakten aufgefüllt.
Krypton nutzt libclang für die Analyse, ein Plugin System für die Erweiterung und Unterstützung weiterer Features, sowie LuaJit für Scripting.
Makefile, CMake, qmake und premake sind weit verbreitet und lösen einzelne Disziplinen sehr gut aber keines kommt nahe einem npm von nodejs oder pip von python.
Krypton ist am ehesten mit npm vergleichbar und geht beim bauen die Wege von premake.

Krypton soll in der Lage sein sich selbst zu bauen, dafür gibt es ein bootstrapping Prozess. In diesem wir mit Visual Studio 2019 C++ eine einzelne c++ Datei gebaut und gelinkt, diese kann dann ausgeführt werden und sorgt für alle weiteren Schritte, bis der finale Optimierte Build raus fällt, welcher dann in der Lage sein soll Cross Platform das Programm zu bauen.

Das Finale Tool soll über Erweiterungen dann neue Compiler und Build Engines und Tools kennen lernen können und über Lua möchte ich spezielle Logik abbilden, die ein Projekt benötigt.

Krypton Object Notation
Das Format erinnert wohl am meisten an INI und JSON, dass liegt daran, dass das KON Format auf Parallelisierung setzt und dies durch eine Information pro Zeile ermöglicht.
Also jeder Zeilenumbruch beendet eine Information und was es für eine Information ist, kann dann beim parsen der Zeile erkannt werden.
Der Hauptprozess geht per SIMD auf die Suche des Zeilenumbruchs(LineFeed) und erzeugt ein parsing Task für den Bereich. Ein AVX512 fähige CPU kann so 64 Zeichen in einer Prüfung schaffen. Der Threadpool kann dann eine Zeile Zeichen für Zeichen verarbeiten, erkennen ob es Objekte, Arrays und so weiter ist und dann entsprechend die Token passend befüllen.
Es gibt in den Format nur Strings, daher findet keine Konvertierung, Validierung statt. Die tokens werden Linear gehalten, dies ist notwendig, da ein End-Object oder End-Array Token rückwärts geht und das Start-Objekt/Array Token sucht und dann alles auf dem Weg dem Start-Token unterordnet.
KON kennt auch keine spaces, wenn man spaces zum einrücken nutzt, dann gehören die Leerzeichen auch zum String.


Bootstrapping
Das Bootstrapping nutzt Windows API und diverse "single file" includes, um ein paar Grundlagen mit zu liefern.
Aktuell ist ein primitiver KON Parser da, der die obige KON Datei liest und verarbeitet. Mit der Windows API lade ich von meinem Paket Server die 3 Pakete und entpacke sie.
Ich verwende tar und lz4, da diese mit sehr wenig Code implementierbar sind.
Mit den 3 Abhängikeiten in ein weiteres Bootstrapping Binary gelinkt, kann ich dann Source Code parsen, Windows unabhängig http/https verarbeiten und Scripting Support machen. Das ist notwendig um dann das finale Buildtool zu bauen.

Paket Repo
Ich will wie bei rpm nicht auf ein Archieve und Kompression fixieren, also jeder packt so wie er will und muss nur mit dem Build Tool und der Plugin Erweiterung auspackbar sein. Im Bootstrapping ist es eine tar file, die mit lz4 gepackt wird aber das ist nicht gut in der Kompression aber sehr schnell beim entpacken. Ich will Tar und LZMA2 verwenden, da wesentlich stärker packen kann.
Die Struktur für die Pakete muss ich noch designen, aktuell liegt einfach alles in einem Ordner und hat keine Versionen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Bootstrapping
Man baut nun mit einem einfachen Kommandozeilen Befehl die main.cpp Datei und führt dann die main.exe aus.
Das wäre Bootstrapper Stage 1, welche folgendes kann.

1. Datei download
2. tar Archive entpacken
3. lz4 Daten entpacken
4. KON Datein laden
5. Binary Pakete laden/verwenden
6. Visual Studio 2019 C++ Support

Mit Stage 1 baue ich Stage 2, in dem ich die KON Datei dafür verarbeite und Interpretiere.

Es wird das luajit-bin-1.0.0.tar.lz4 und ppmd-mini-1.0.0.tar.lz4 Paket vom Paketserver geladen, entpackt und die KON Dateien der Pakete eingelesen und interpretiert.
Dann wird mit der Visual Studio 2019 C++ Build Engine die main1.cpp gebaut und mit LuaJit und ppmd gelinkt.
Bootstrapper Stage 2 kann nun folgendes zusätzlich.

1. PPMD Kompression
2. Modul support
3. git support über Lua Modul
4. cmake support über Lua Modul

Die Module sind Erweiterungen für die Interpretation von KON Dateien.
Man kann sie mit C++ Code bauen oder über das LuaModul Objekt Lua Scripte aufrufen.
Dabei werden alle Werte, die in der KON, für das Modul, hinterlegt worden übergeben und die Rückgabe wird in einem Variablen Register, im Krypton Builder Prozess gemerkt.
Hier mal ein Beispiel für das xxhash Paket.

Stage 2 schaut im source und build.generator Objekt, ob dort ein weiteres Objekt liegt und wenn ja, mit welchem Namen.
Anhand des namen wird in dem Modulregister geguckt und bei einem Treffer eine Instanz erzeugt, die Konfigurationsdaten übergeben und ausgeführt.
In dem Beispiel wird also das LuaModul git instanziert, die Werte übergeben, ausgeführt und dann der Pfad, wo das Repo ausgecheckt wurde zurück gegeben.
Später, im Build Schritt, wird dann ein Generator verwendet, anstatt des internen Build Systems.
In dem Fall wird das LuaModul cmake instanziert, die Werte übergeben, ausgeführt und dann der Pfad zum build Verzeichnis übergeben.
Das Paket besitzt noch ein Publish und Export Bereich.
Publish ist für das installieren und von einem Paket gedacht und in dem Beispiel wird die DLL in das Binary Verzeichnis von Krypton build system kopiert, damit jedes Programm diese findet.
Export ist für den Build wichtig, alle Daten werden an das Paket weiter gegeben, welches dieses Paket verwendet. Also Include und Library Pfade werden mit im Build Prozess des zu bauenden Paketes mit übernommen und Libs zusätzlich gelinkt.

Die Stage 2 baut das Krypton Paket Management Programm kpm.

kpm
Ich hab mich entschieden, dass ich 2 Binaries anbieten will, kpm und kbuild.
Um nicht jeden mein kbuild auf zu drücken, hab ich kpm, welches nur Paketverwaltung macht und somit auch für ganz andere Zwecke verwendbar ist, z.B. Delphi Pakete
Also um das Tool zu bauen wird Stage 2 mit der kpm.kon Datei als Parameter aufgerufen und das finale Tool fällt raus.
Aktuell sieht die KON Datei wie folgt aus und nutzt kbuild Mechaniken aus der Stage 2.

Aktuell arbeite ich am bauen von Paketen und im ganz speziellen baue ich ein eigenes Format, welches jede Datei einzeln packen kann und auch Unterstützung für Patches hat.
Ich hatte ein bisschen Data-Mining betrieben, um raus zu bekommen, was so für kosten auf mich zukommen würden, wenn ich alles hosten lasse und der Traffic ist ziemlich teuer.
Also hatte ich beschlossen die Pakete so klein wie möglich zu bekommen und mir entsprechend Verfahren angeguckt, auch zum Thema Updates.
Für normale Pakete will ich Context sensitiv komprimieren und mit cluster based delta compression experimentieren. Zweites ist ein recht rechenintensives Konzept, wo man jede Datei in einem Paket mit einem Graphen-Knoten repräsentiert und man Unkompremiert, Delta-Komprimierung zwischen allen Knoten und einfache Kompression testet, die Kanten zwischen den Nodes dann die Größe als Gewichtung setzt und dann die geringsten Kosten den Graphen abläuft. Das Ergebnis ist das kleinst mögliche Ergebnis Paket.
Für Updates funktioniert das natürlich super, da sich wenig ändert.

Infrastruktur
Ich hab nun in mein neuen Büro eine 100down/48up DSL Leitung mit Statischer IP legen lassen und bereits einen von mein 2 Servern in betrieb genommen :>
Bei Ebay hatte ich zwei HP Proliant Server mit alten dual Socket 6Kern Xeon, 16GB RAM und 8 600GB SAS Platten besorgt. Diese Server sind ziemlich günstig machen was sie sollen und sind ideal für mich ^^
Also hab ich insgesamt 48 Logische Prozessoren, 32GB RAM und 4,8TB Festplatten, um die Update Pakete zu berechnen, bereit zu stellen und zu lagern.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Diese Projekt macht echt spaß und ich brauch wohl Hilfe es erfolgreich aus zu rollen

Web-Service
Ich hab mir für das Paket Verzeichnis die naheliegende Domain package.directory kaufen können
Also werde ich, wenn ich niemanden finden kann der mir Hilft oder bessere Vorschläge macht, dort bald folgendes Konstrukt laufen lassen.
AWS ELB mit einem Container
NodeJS, express-graphql für die Applikation
Bootstrap 4, jquery für die Website
Redis als Memory Datenbank
Die Paketdaten werden von Jenkins in json zusammen gefasst und dann bei Erfolg in Redis gepackt und ins file system der node Instanzen.
File Download wird auf meinem Office Server passieren.

KPM
Der Package Manager baut nun durch die Stages durch das finale Tool.

Dort habe ich schon das generieren von Paketen eingebaut und habe als letztes am Ausrollen der Pakete gearbeitet.
Dabei habe ich noch ein bisschen mit den Kompressionsalgorithmen gearbeitet und sie vergleicht.
Meine Vermutung, dass ich mit einem eigenen Format und ppmd kleiner bin als mit typische Lösungen wie 7z(lzma2), tar.xz(ppmd) oder tar.lz4 hat sich bestätigt.
Das wird in der Zukunft noch stärker verkleinert werden, wenn ich mich intensiver mit dem Thema beschäftige aber erstmal brauch ich nur eine Lösung und nicht die Perfekte Lösung.

Ich hab es nun auch so gebaut, dass es keine Abhängigkeiten mehr hat. Es ist eine einzige Binary wo Lua und co mit drin ist und knapp 413KB groß ist. Da geht noch einiges an der Größe aber das hat aktuell keine Priorität, erstmal fertig machen.

Ich hab mir nun auch noch cargo von Rust angeguckt und will schauen, davon zu lernen und Möglichst viele gute Ideen zu übernehmen.
Cargo hat z.B. auch die Möglichkeit nur eine Crate/Paket zu registrieren aber dann den code von einem git repo zu holen oder von einem 3rd Party Server.
Man versucht cargo.io als Zentrales Register zu etablieren aber bietet halt die anderen Möglichkeiten noch mit an.
Mir gefällt auch die Lösung für die Konfiguration auf OS und Architektur in deren Konfiguration.

Die nächsten Schritte sind das installieren, registrieren von Paketen und der Web-Service.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004