AW: oscam mit Simplebuild und emu kompilieren Ubuntu
Ich nutze folgendes Script "emupatch.sh" im simplebuild-Verzeichnis, welches ich vor "simplebuild menu" aufrufe:
Code:
#!/bin/sh
rm oscam-emu.patch 2>/dev/null
wget https://raw.githubusercontent.com/oscam-emu/oscam-emu/master/oscam-emu.patch 2>/dev/null
rm -rf oscam-svn 2>/dev/null
./simplebuild checkout
cd oscam-svn
patch -p0 < ../oscam-emu.patch
cd ..
Das funktioniert aber nur
- bei einem jungfräulichen simplebuild
oder
- nach dem Löschen der existierenden Build-Konfigurationen aus ./toolchains/configs
oder
- nach manuellem Zufügen von "#define WITH_EMU 1" in den schon vorhandenen *.config.h.saved" (Davon gibt es für jede Toolchain eine)
Andernfalls vergißt simplebuild die Einstellung für mit/ohne EMU sofort wieder, wenn man das Add-Ons-Menü verläßt.
Trotzdem hat das Script diverse Vorteile:
- hat man so immer den aktuellen Patch, der wird nämlich ähnlich oft überarbeitet wie oscam selber (Siehe auch nächster Punkt)
- sieht man den Patchvorgang am Ende auf dem Bildschirm.
Wenn da "rejects" auftauchen (Und das tun sie immer wieder mal) oder zu viel fuzz oder offsets, dann kann man sich das Bauen auch gleich schenken, denn dann paßt der Patch nicht mehr zum aktuellen oscam-svn und muß erst angepaßt werden.
Bestenfalls scheitert das Bauen eh, schlimmer wäre, daß am Ende ein teilweise lauffähiger Build mit obskuren Fehlern rauskommt, die nur in Deinem eigenen oscam sind und die sich und Dir niemand erklären können wird.
- kann man dann immer noch andere Patches über Patches an/aus einspielen oder eben nicht einspielen, ohne gleichzeitig auch immer den Emu zu aktivieren.
PS:
Eine kurze Erklärung, wieso man Patches mit fuzz mit Vorsicht und mit rejects gar nicht benutzen sollte:
"fuzz" bei einem Patch bedeutet, daß die Zeilen - welche die durch den Patch zu ändernden, zu löschenden oder zuzufügenden Zeilen - umgeben, mehr oder minder geringfügig verändert wurden. Diese Änderungen können tatsächlich so geringfügig sein, daß sich nichts am Programmablauf ändert (z.B. die whitespace-fixes¹, die ich am meisten hasse), sie können es aber auch in sich haben.
Bei "rejects" wurde ein Teil des Patches nicht angewandt, weil Patch die zu patchende Stelle gar nicht mehr erkennen konnte, so stark wurde sie inzwischen verändert. Dementsprechend fehlt dann ein Teil des Patches und sowieso arbeitet das ursprüngliche Programm an der zu patchenden Stelle auch schon im Urzustand ganz anders.
Bei "offset" ist die zu ändernde Stelle nicht mehr in derselben Zeile wie beim Erstellen des Patches. Auch hier kann dazwischen eine Menge an Änderungen passiert sein, durch die der Patch nutzlos oder gar schädlich wird.
Eine Handvoll Zeilen offset ist i.d.R. harmlos, aber je größer der Offset wird, desto wahrscheinlicher ist, daß da auch im Resultat was anderes rauskommt.
¹: whitespace fixes sind "Nichtänderungen":
whitespaces sind Leerstellen oder Tabulatorschritte.
Irgendein Megaästhet hat sich da an (nutzlosen) Leerstellen am Ende oder 4 Leerstellen statt einem Tabstop gestört und das angepaßt. Bei praktisch allen Programmiersprachen außer Python sind whitespace-Änderungen 200% wirkungslos, bei Python haben whitespaces zwar eine Auswirkung, aber dann bezeichnet man die Änderung auch nicht mehr als whitespace-Fix. whitespace-Fixes sind immer rein kosmetisch.
Wer reine whitespace-Fixes macht, braucht mal einen Sack Leertasten im Hintern, denn whitespace-Fixes führen trotz Null funktionaler Änderungen dazu, daß z.B. Millionen von Enigma2-Boxen das unveränderte Plugin beim nächsten Update neu ziehen, Entwickler ihre Patches und Commits neu anpassen müssen, usw. usf.
Last but not least produziert es enttäuschte Nutzer, die sich angesichts des Pseudo-Updates von <fehlerhaftes Plugin hier einfügen> auf die Behebung des Bugs freuen und dann feststellen, daß absolut gar nichts anders ist.
