Nützlich oder nicht?

Was als vage Idee mit einem seltsam eingrenzenden (um nicht zu sagen “beschränkten”) Titel begann, ist inzwischen schon recht gut benutzbar. AccessMake ist inzwischen schon weit davon entfernt, nur noch für Access da zu sein. Noch kann es nicht alles, aber was es kann, das gefällt mir schon mal recht gut.

Lasst mich nochmal kurz auf die Grundidee eingehen. Wenn wir eine Software installieren, erwarten wir doch, dass es ein Setup gibt, und dass das Setup uns vorab mitteilt, welche Version es im Begriff ist zu installieren. Diese Frage kann man unterschiedlich beantworten:

  • Versionsnummer
  • Datum und vielleicht Uhrzeit
  • eine laufende Nummer
  • Hashwert

Davon abgesehen kann es ruhig auch irgendein seltsamer Name sein, der so überhaupt gar nichts mit Software zu tun hat. Ein Tier vielleicht, eine Eis-Sorte, eine römische Gottheit oder eine zunehmende Annäherung an die Zahl Pi. Wie auch immer, dieselbe Information muss später auch im Programm selbst dargestellt werden, und beide müssen gefälligst identisch sein! Ebenfalls könnte es sein, dass die Dokumentation automatisch generiert wird, und auch auf deren Titelseite wäre es nicht schlecht, die Versionsinformation zu lesen. Nehmen wir noch das Release-Datum und (besonders für Builds während der Testphase) den Hashwert hinzu (natürlich sowohl im Setup als auch im Programm selbst), dann haben wir in diesem Gedankenexperiment schon 3 x 2 Stellen, an denen dieselbe Information zu stehen hat. Viel Spaß, das alles per Hand zu machen!

Aber wir denken ja an einen automatischen Buildprozess. Nehmen wir also an, jeweils eine dieser Stellen sei die Basis, und die anderen Stellen müssten diese Information von der Basis nehmen und verwenden. In meinen Access-Applikationen ist das stets eine Konstante, die in einem Modul Globals deklariert ist:

Public Const APP_VERSION = "1.2.3"

Mein amake.exe soll nun die Information 1.2.3 von dieser Stelle lesen und zum Beispiel in eine Konstantendeklaration für Inno Setup schreiben, denn das will ich nicht jedes mal von Hand tun müssen:

#define MyAppVersion "1.2.3"

Das Datum beschaffen wir uns natürlich vom System, den Hashwert von Git via git rev-parse --short HEAD. Ich habe nun folgende Sprache (eine sog. DSL) erfunden, die dies für AccessMake definiert. Um die Versionsnummer aus dem Quellcode zu lesen und in das Setup-Script zu schreiben:

READ app\source\M_Globals.def USING Public +Const +APP_VERSION.*= +"([0-9.]*)"

WRITE setup\setup.iss USING #define +MyAppVersion +"([0-9.]*)"

Abstrahiert dargestellt sehen die Befehle so aus (pro Befehl eine Zeile):

READ filename USING regex
WRITE filename USING regex

Dadurch lässt sich das selbe Programm an verschiedene Softwareumgebungen anpassen. Die einzige Voraussetzung ist, dass alle für den Buildvorgang notwendigen Informationen vor dessen Durchführung in Textdateien vorliegen.

Das aktuelle Datum erhalten wir mit GET isodate und schreiben es mit dem schon bekannten WRITE-Befehl an die gewünschte Stelle.

Das Programm ist noch nicht ganz fertig, aber ich persönlich setze es in meinen Access-Projekten bereits ein. Es kann von der folgenden Adresse heruntergeladen werden: https://gitlab.com/juengling/AccessMake. Weitere Informationen finden sich auf der Dokumentationsseite https://juengling.gitlab.io/AccessMake-Doc/.

Ähnliche Artikel:

Schreibe einen Kommentar

Deine Email-Adresse wird nicht veröffentlicht.

sieben + 3 =