64bit Versionen + unified Installationsarchiv

[jens-maus]

Aktuell wird CCU-Jack gerade für virtuelle Systeme nur als x86/i686 (32bit) binary ausgeliefert das statisch gelinkt ist. Für ein verbessertes Speichermanagment und für eine bessere Performance wäre es aber durchaus wünschenswert wenn CCU-Jack auch als x86_64 (64bit) Variante ausgeliefert werden könnte. Das selbe gilt natürlich auch für die ARM Varianten die es aktuell nur als armhf binaries gibt, jedoch RaspberryMatic für rpi3 und rpi4 aarch64 als native Platform einsetzt. Auch hier wäre es wünschenswert 64bit Variante auszuliefern.

Zusätzlich wäre es sicherlich auch gut gerade die CCU-Addon Versionen ggf. in ein einzelnes Installationspaket zu packen, sodass hier nicht der Endanwender am Schluss die Auswahl des richtigen tar.gz treffen müsste. Hierzu müsste man einfach nur z.B. im update_script an den entsprechenden Stellen dann das jeweils "richtige" Binary an seinen Platz kopieren.

[Baxxy13]

Die Version für den Pi4B dürfte 64bit sein, die läuft auf RM auch auf 3er Pi's.
Ich hatte Mathias dazu mal gefragt...
Forum-Link

[jens-maus]

Das stimmt. Das wird so sein. Umsomehr halte ich es für sinnvoll doch einfach alle binaries in ein einzelnes tar.gz zu packen das man dann entsprechend auf seien CCU/RaspberryMatic hochlädt und dann entscheidet das update_script dynamisch anhand der Host-Architektur (32 vs. 64bit, CCU3 vs. RaspberryMatic) welches Binary konkret installiert wird. Wie @mdzio ja bereits in dem forum link richtig festgestellt hat ist es schon jetzt eigentlich zu komplex welches tar.gz man runterladen muss und welches nicht. Das sollte man daher dem update_script überlassen, auch wenn damit das CCU-Addon Archiv damit wesentlich größer wird. Aber die paar MB mehr sollte man sich leisten. Ist im Grunde die gleiche Diskussion wie mit CUxD. Auch da passiert es ja regelmäßig das jemand die falsche Version versucht zu installieren und sich dann in die Füße schießst. Das sollte und darf eigentlich nicht passieren. Und dann eben auch gleich noch eine x86_64 version mit rein und dann sind alle Platformen entsprechend abgedeckt und man muss nur noch eine einzelne ccu-jack-2.8.0.tar.gz anbieten die man unter Zusatzsoftware hochlädt, egal welche Platform man hat.

[jens-maus]

So, ich hab mir mal erlaubt da etwas vorzubereiten (siehe #163). Auf der einen Seite sollte das nun auch ein x86_64 64bit addon bauen.

Auch bringt #163 dann noch ein basic github workflow file mit sich das für jeden checkin in den master branch dann den Go build als continous integration maßnahme ablaufen lässt und am schluss die .tar.gz/.zip files in ein upload artifact in den workflow hochlädt. Basierend darauf könnte/sollte man dann ein etwas komplexeres workflow entwickeln können den man dann auch für das generieren eines neuen releases nutzen könnte. Auch könnte man darüber dann das unified-addon-archiv z.b. generieren lassen wenn das gewünscht ist. @mdzio schau es dir mal an, vielleicht magst du das ja übernehmen.

[jens-maus]

@mdzio Danke fürs mergen des PR. Hab gesehen du hast nen extra branch dafür aufgemacht in dem du auch ein Dokument bzgl. Rpi armvX Architekturen abgelegt hast. Für das Addon ist das aber alles irrelevant. Da musst du im grunde nur im update_script den Rückgabewert von uname -m während des Installationsprozesses überprüfen um dann das entsprechend passende addon binary installieren zu lassen. Du solltest nicht versuchen jetzt rauszufinden welcher RaspberryPi oder ARM System dahintersteckt, sondern einfach blind uname -m vertrauen...

[mdzio]

uname -m hatte ich mir auch bereits für die Erkennung der Architektur heraus gesucht. Daraufhin habe ich mir dann folgende Liste mit den Rückgabewerten zusammengesucht, und diese dann auf die nötigen Compiler-Einstellungen abgebildet:

armv6l         -> GOARCH=arm, GOARM=6
armv7l         -> GOARCH=arm, GOARM=7
arm64, aarch64 -> GOARCH=arm64
i386, i686     -> GOARCH=386
x86_64, amd64  -> GOARCH=amd64

@jens-maus Enthält diese Liste alle möglichen Rückgaben der verschiedenen RaspberryMatic-Distributionen? Oder kann z.B. i386, i686 entfallen, da es dafür keine RM-Distribution gibt? Für armv7l würde ich auch gerne das gleiche Binary wir für armv6l nehmen, damit es nicht zu viele Binaries werden.