Viele Menschen schreiben ein Make-Tool, so habe ich es nun auch getan, allerdings nicht ganz vollständig.
Mein Use-Case war es Pre-Build-Ereignisse in einen MSBuild-Bauprozess einzubauen. Dies konnte die Erzeugung einer kleinen Datei sein, der Aufruf des Typescript Compilers oder das Zusammenkopieren von Dateien.
Zuvor hatte ich eine Mischung aus MSBuild-Kommandos und Cake genutzt. Gerade Cake finde ich sehr schön, da es auf der C#-Sprache selbst aufsetzt.
Dass Cake bei jedem Kompilations-Vorgang erstmal das Cake-File kompiliert hatte, stört mich schon ein wenig, da je nach Rechner ein paar Sekunden verloren gehen.
Die Anforderungen an das neue Tool waren folgendermaßen. Insbesondere war es für mich wichtig, dass ich die Mächtigkeit von MSBuild nutzen kann, da ich nicht ‘yet another’ Tool schreiben wollte.
Kurz gesagt: https://github.com/mbrenn/BurnSystems.Make/blob/main/docs/design.adoc
- MSBuild unterstützt nur relativ umständlich kompliziertere Build-Skripte.
- Cake möchte jedes mal kompilieren und unterstützt kein Syntax-Highlighting im build.cake file.
- Nuke wird leider nicht mehr gepflegt. Dieses Projekt sah auf dem ersten Blick einfach ideal aus.
Requirements
- The build process shall run on Windows and Linux
- The build process shall support C#, TypeScript and other Project Types.
- The build process will be integrated with MS Build.
- BSMake shall be callable on its own (and does not call MS Build).
- BSMake can be called from MSBuild to get advantage by all the MSBuild Features (e.g. incremental build, build dependency tree, etc)
- The configuration file shall be written in C#.
- The build process shall only execute steps in case the corresponding source files have been modified. This avoids a full recompilation and is called ‘incremental build’.
- The build process does not require a compilation step upon each build. It checks whether the configuration file has changed and will only perform the compilation in case it has been altered.
- The build process supports project-specific compilations which can be called individually. This means that every project can have its own build configuration and there is no need to integrate everything on solution-level.
- The solution-level can include its own build process which integrates all project-level builds. This can be done hierarchically.
- The solution-level does not define the order and priority of build steps explicitly since it calls MS Build on Solution (.slnx). The MS Build process there already knows the right order.
- The editor of Rider or Visual Studio shall support syntax-highlighting of the build files.
- The build process is required to be integrated into ‘dotnet tool’ to allow easy installation.
- The build configuration files do not interfere with the project files and may not be compiled into the project files themselves
- The outputs or intermediate files of the build process are consolidated into one directory per project.
- The build process shall support different Configuration contexts (e.g. Debug / Release)
- All dynamically created artifacts of bsmake shall be cleanable by a simple call, so the next build process does not incldue any cached artifacts.
Resultat
Die Version 1.0.1 wurde eben veröffentlicht und unterstützt ein einfaches Executable.
Dieses liegt im .bsmake-Verzeichnis
Beim ersten Aufruf wird das File komplett kompiliert:
Beim zweiten Aufruf als gecachete Version wiedergenutzt:
Die Datei Primes.cs liegt dann im Projekt-Verzeichnis und wird vom Projekt-Kompilat dann verwendet.
Schnell und einfach.
Weitere Dokumentation unter: https://github.com/mbrenn/BurnSystems.Make/blob/main/docs/design.adoc
