64bit Versionen + unified Installationsarchiv about ccu-jack HOT 5 OPEN

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.

from ccu-jack.

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

from ccu-jack.

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.

from ccu-jack.

@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...

from ccu-jack.

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.

from ccu-jack.