🥇Mein fünfter Tag mit Haiku: Lasst uns ein bisschen Software portieren

TL;DR: Ein Neuling sah Haiku zum ersten Mal und versucht, einige Programme aus der Linux-Welt zu portieren.

Mein erstes für Haiku portiertes Programm, verpackt in dessen hpkg-Format.

Kürzlich Ich habe Haiku entdeckt, ein überraschend gutes Betriebssystem für PCs.
Heute werde ich lernen, neue Programme auf dieses Betriebssystem zu portieren. Der Schwerpunkt liegt auf der Beschreibung meiner ersten Erfahrungen beim Umstieg auf Haiku aus der Perspektive eines Linux-Entwicklers. Ich entschuldige mich im Voraus für die dummen Fehler, die ich während des Prozesses gemacht habe, denn seit meiner ersten Installation von Haiku ist noch nicht einmal eine Woche vergangen.

Ich möchte drei Ziele erreichen:

Ein einfaches CLI-Programm portieren.
Ein GUI-Programm mit Qt portieren.
Diese dann in das hpkg-Format packen (da ich immer noch an einer Anpassung von AppDir und AppImage für Haiku nachdenke…).

Lass uns anfangen. In den Abschnitten Dokumentation und Entwicklung, sowie in wiki von HaikuPorts habe ich die richtige Richtung gefunden. Es gibt sogar ein Online-PDF-Buch. BeOS: Portierung von Unix-Anwendungen..
467 Seiten – und das seit 1997! Es ist beängstigend, hineinzuschauen, aber ich hoffe auf das Beste. Ermutigend sind die Worte des Entwicklers: "Es hat lange gedauert, da BeOS nicht POSIX-kompatibel war", aber Haiku ist "größtenteils" bereits so.

Portierung eines einfachen CLI-Programms.

Der erste Gedanke war, die Anwendung avrdudezu portieren, aber wie sich herausstellte, ist dies schon lange her. die Unterstützung für die Version etcd2 eingestellt. Vor langer Zeit.

Der erste Versuch: nichts zu sehen.

Was ich nicht verstehen kann, ist, dass schon seit über 10 Jahren Anwendungen für Haiku portiert werden. Dabei hat das Betriebssystem selbst nicht einmal die Version 1.0. Der zweite Versuch: es muss neu geschrieben werden.

Ich werde also

ptouch-770 , ein CLI zur Steuerung des Brother P-Touch 770-Druckers, den ich für Etiketten benutze.Ich drucke verschiedene Etiketten darauf, und ihr habt ihn möglicherweise schon in meinem vorherigen Artikel gesehen. Kurz zuvor hatte ich ein kleines Wrapper-Programm mit GUI in Python geschrieben (da es auf Gtk+ basiert, wird es umgeschrieben werden müssen, und das ist eine gute Gelegenheit, um etwas zu lernen).
Brother P-Touch 770 Etikettendrucker. Wird er unter Haiku funktionieren?

Der Haiku-Paketmanager kennt die Bibliotheken und Befehle, daher, wenn ich die Nachricht "Cannot find libintl" beim Starten erhalte,

starte ich einfach configure pkgman install devel:libintl und das benötigte Paket wird gefunden. Ähnlich bei pkgman install cmd:rsync. Nun ja, und so weiter.Außer in Fällen, in denen es nicht funktioniert:

Vielleicht ist udev zu sehr Linux-like, weshalb es nicht für Haiku existiert. Das bedeutet, dass ich den Quellcode, den ich versuche zu kompilieren, anpassen muss.

/Haiku/home> git clone https://github.com/probonopd/ptouch-770
Cloning into 'ptouch-770'...
remote: Enumerating objects: 134, done.
remote: Total 134 (delta 0), reused 0 (delta 0), pack-reused 134
Receiving objects: 100% (134/134), 98.91 KiB | 637.00 KiB/s, done.
Resolving deltas: 100% (71/71), done./Haiku/home> cd ptouch-770//Haiku/home/ptouch-770> make
gcc -Wall -O2 -c -o ptouch-770-write.o ptouch-770-write.c
ptouch-770-write.c:28:10: fatal error: libudev.h: No such file or directory
 #include <libudev.h>
          ^~~~~~~~~~~
compilation terminated.
Makefile:16: recipe for target 'ptouch-770-write.o' failed
make: *** [ptouch-770-write.o] Error 1/Haiku/home/ptouch-770> pkgman install devel:libudev
100% repochecksum-1 [65 bytes]
Validating checksum for Haiku...done.
100% repochecksum-1 [64 bytes]
Validating checksum for HaikuPorts...done.
*** Failed to find a match for "devel:libudev": Name not found/Haiku/home/ptouch-770> pkgman install devel:udev
100% repochecksum-1 [65 bytes]
Validating checksum for Haiku...done.
100% repochecksum-1 [64 bytes]
Validating checksum for HaikuPorts...done.
*** Failed to find a match for "devel:udev": Name not found

Vielleicht ist udev zu linuxlastig, deshalb gibt es es nicht für Haiku. Dies bedeutet, dass ich den Quellcode, den ich versuche zu kompilieren, bearbeiten muss.
Ach, man kann nicht höher springen, als man kann, und ich weiß nicht einmal, wo ich anfangen soll.

Dritter Versuch

Es wäre schön, tmate für Haiku, dann würde ich den Entwicklern von Haiku erlauben, sich mit meiner Terminalsitzung zu verbinden – falls etwas schiefgeht. Die Anweisungen sind ziemlich einfach:

./autogen.sh
./configure
make
make install

Sieht gut aus, also warum nicht versuchen, es auf Haiku zu verwenden?

/Haiku/home> git clone https://github.com/tmate-io/tmate/Haiku/home> cd tmate//Haiku/home/tmate> ./autogen.sh
(...)/Haiku/home/tmate> ./configure
(...)
checking for libevent... no
checking for library containing event_init... no
configure: error: "libevent not found"/Haiku/home/tmate> pkgman install devel:libevent
(...)
The following changes will be made:
  in system:
    install package libevent21-2.1.8-2 from repository HaikuPorts
    install package libevent21_devel-2.1.8-2 from repository HaikuPorts
Continue? [yes/no] (yes) :
100% libevent21-2.1.8-2-x86_64.hpkg [965.22 KiB]
(...)
[system] Done.checking for ncurses... no
checking for library containing setupterm... no
configure: error: "curses not found"/Haiku/home/tmate> pkgman install devel:libcurses
(...)
*** Failed to find a match for "devel:libcurses": Name not found/Haiku/home/tmate> pkgman install devel:curses
(...)
*** Failed to find a match for "devel:curses": Name not found

An dieser Stelle öffne ich HaikuDepot und suche nach curses.
Etwas gefunden, das mir einen Hinweis für eine bessere Anfrage gegeben hat:

/Haiku/home/tmate> pkgman install devel:libncurses
(...)
100% ncurses6_devel-6.1-1-x86_64.hpkg [835.62 KiB]
(...)./configure
(...)
checking for msgpack >= 1.1.0... no
configure: error: "msgpack >= 1.1.0 not found"/Haiku/home/tmate> pkgman install devel:msgpack
(...)
*** Failed to find a match for "devel:msgpack": Name not found/Haiku/home/tmate> pkgman install devel:libmsgpack
(...)
*** Failed to find a match for "devel:libmsgpack": Name not found

Ich bin wieder zu HaikuDepot gegangen und habe natürlich gefunden devel:msgpack_c_cpp_devel. Was für seltsame Namen?

/Haiku/home/tmate> pkgman install devel:msgpack_c_cpp_devel
100% repochecksum-1 [65 bytes]
Validating checksum for Haiku...done.
100% repochecksum-1 [64 bytes]
Validating checksum for HaikuPorts...done.
*** Failed to find a match for "devel:msgpack_c_cpp_devel": Name not found# Why is it not finding it? To hell with the "devel:".../Haiku/home/tmate> pkgman install msgpack_c_cpp_devel
(...)
The following changes will be made:
  in system:
    install package msgpack_c_cpp-3.1.1-1 from repository HaikuPorts
    install package msgpack_c_cpp_devel-3.1.1-1 from repository HaikuPorts
Continue? [yes/no] (yes) :
(...)/Haiku/home/tmate> ./configure
(...)
checking for libssh >= 0.8.4... no
configure: error: "libssh >= 0.8.4 not found"/Haiku/home/tmate> pkgman install devel:libssh/Haiku/home/tmate> make
(...)
In file included from /boot/system/develop/headers/msgpack.h:22,
                 from tmate.h:5,
                 from cfg.c:29:
/boot/system/develop/headers/msgpack/vrefbuffer.h:19:8: error: redefinition of struct iovec'
 struct iovec {
        ^~~~~
In file included from tmux.h:27,
                 from cfg.c:28:
/boot/system/develop/headers/posix/sys/uio.h:12:16: note: originally defined here
 typedef struct iovec {
                ^~~~~
Makefile:969: recipe for target 'cfg.o' failed
make: *** [cfg.o] Error 1

In diesem Schritt wurde mir klar, dass das Portieren eines Programms auf Haiku deutlich mehr Wissen erfordert als nur für einen einfachen Neubau.
Ich habe mit einigen freundlichen Entwicklern von Haiku gesprochen, es stellte sich heraus, dass es einen Fehler in msgpack gibt, und nach ein paar Minuten sehe ich den Patch in HaikuPorts. Ich beobachte, wie das korrigierte Paket hier gebaut wird (buildslave – virtuelle Maschinen).

Der Bau von korrigiertem msgpack auf dem buildmaster

In der Zwischenzeit sende ich den Patch an upstream um die Unterstützung von Haiku in msgpack hinzuzufügen.

Fünf Minuten später ist das aktualisierte msgpack bereits in Haiku verfügbar:

/Haiku/home/tmate> pkgman update
(...)
The following changes will be made:
  in system:
    upgrade package msgpack_c_cpp-3.1.1-1 to 3.2.0-2 from repository HaikuPorts
    upgrade package msgpack_c_cpp_devel-3.1.1-1 to 3.2.0-2 from repository HaikuPorts
Continue? [yes/no] (yes) : y
100% msgpack_c_cpp-3.2.0-2-x86_64.hpkg [13.43 KiB]
(...)
[system] Done.

Überraschend gut. Habe ich das gesagt?!

Ich gehe zurück zur ursprünglichen Aufgabe:

/Haiku/home/tmate> make
(...)
In file included from tmux.h:40,
                 from tty.c:32:
compat.h:266: warning: "AT_FDCWD" redefined
 #define AT_FDCWD -100

In file included from tty.c:25:
/boot/system/develop/headers/posix/fcntl.h:62: note: this is the location of the previous definition
 #define AT_FDCWD  (-1)  /* CWD FD for the *at() functions */

tty.c: In function 'tty_init_termios':
tty.c:278:48: error: 'IMAXBEL' undeclared (first use in this function); did you mean 'MAXLABEL'?
  tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|IMAXBEL|ISTRIP);
                                                ^~~~~~~
                                                MAXLABEL
tty.c:278:48: note: each undeclared identifier is reported only once for each function it appears in
Makefile:969: recipe for target 'tty.o' failed
make: *** [tty.o] Error 1

Jetzt scheint msgpack nicht schuld zu sein. Ich kommentiere IMAXLABEL in tty.c so:

tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|/*IMAXBEL|*/ISTRIP);

Ergebnis:

osdep-unknown.c: In Funktion 'osdep_get_cwd':
osdep-unknown.c:32:19: Warnung: ungenutzter Parameter 'fd' [-Wunused-parameter]
osdep_get_cwd(int fd)
               ~~~~^~
make: *** Keine Regel, um Ziel 'compat/forkpty-unknown.c' zu erstellen, benötigt von 'compat/forkpty-unknown.o'. Stop.

Nun, das schon wieder… Übrigens:

/Haiku/home/tmate> ./configure | grep -i OPENAT
checking for openat... no

mr. waddlesplash zeigt mir, wo ich graben soll:

/Haiku/home/tmate> ./configure LDFLAGS="-lbsd"
(...)/Haiku/home/tmate> make
(...)
In file included from tmux.h:40,
                 from window.c:31:
compat.h:266: warning: "AT_FDCWD" redefined
 #define AT_FDCWD -100

In file included from window.c:22:
/boot/system/develop/headers/posix/fcntl.h:62: note: this is the location of the previous definition
 #define AT_FDCWD  (-1)  /* CWD FD for the *at() functions */

make: *** No rule to make target 'compat/forkpty-unknown.c', needed by 'compat/forkpty-unknown.o'.  Stop.

Hier habe ich hochgeladen config.log.

Mir wurde erklärt, dass es zu libresolv auf Haiku noch etwas in libnetwork gibt. Offensichtlich muss ich den Code weiter anpassen. Ich muss nachdenken…

find . -type f -exec sed -i -e 's|lresolv|lnetwork|g' {} ;

Die ewige Frage: Was passiert hier.

/Haiku/home/tmate> ./configure LDFLAGS="-lbsd"
(...)/Haiku/home/tmate> make
(...)
# Success!# Let's run it:/Haiku/home/tmate> ./tmate
runtime_loader: /boot/system/lib/libssh.so.4.7.2: Could not resolve symbol '__stack_chk_guard'
resolve symbol "__stack_chk_guard" returned: -2147478780
runtime_loader: /boot/system/lib/libssh.so.4.7.2: Troubles relocating: Symbol not found

Das gleiche, nur detaillierter. Ich habe gegoogelt und fand das. Wenn ich hinzufüge -lssp hilft es 'manchmal', ich probiere:

/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp"
(...)/Haiku/home/tmate> make
(...)/Haiku/home/tmate> ./tmate

Wow! Es startet! Aber…

[tmate] ssh.tmate.io Lookup-Fehler. Erneuter Versuch in 2 Sekunden (nicht wiederherstellbarer Fehler bei der Namensauflösung)

Ich werde versuchen, zu debuggen, die Datei ist hier:

/Haiku/home/tmate> strace -f ./tmate >log 2>&1

„Bad port ID“ – das ist schon wie eine Visitenkarte haiku.Vielleicht hat jemand eine Idee, was falsch ist und wie man das beheben kann? Falls ja, werde ich den Artikel aktualisieren. Link zu GitHub.

Der Portierung einer GUI-Anwendung auf Qt.

Ich wähle eine einfache QML-Anwendung.

/> cd /Haiku/home//Haiku/home> git clone https://github.com/probonopd/QtQuickApp
/Haiku/home/QtQuickApp> qmake .
/Haiku/home/QtQuickApp> make
/Haiku/home/QtQuickApp> ./QtQuickApp # Works!

Echt einfach. Weniger als eine Minute!

Verpackung von Anwendungen in hpkg unter Verwendung von haikuporter und haikuports.

Wo soll ich anfangen? Es gibt keine einfache Dokumentation, ich gehe auf den Kanal #haiku in irc.freenode.net und höre:

Team package — ein niedrigstufiger Weg zur Erstellung von Paketen. In der Regel reicht es aus, PackageInfo zu verwenden, wie im Abschnitt „Making it into a proper .hpkg package“ beschrieben.
Ich muss etwas tun solches
Man kann verwenden hpkg-creator (bei mir stürzt es ab, Fehlerbericht)

Ich verstehe nicht, was ich tun soll. Ich nehme an, ich brauche ein Anfängerhandbuch im Stil von „Hallo Welt!“, idealerweise ein Video. Es wäre auch schön, eine benutzerfreundliche Einführung in HaikuPorter zu bekommen, wie sie bei GNU hello gemacht wurde.

Ich lese Folgendes:

haikuporter ist ein Werkzeug zum Erstellen allgemeiner Paketprojekte für Haiku. Es verwendet das HaikuPorts-Repository als Grundlage für alle Pakete. Zum Erstellen von Paketen werden die Rezepte von haikuporter verwendet.

Zusätzlich erfahre ich, dass:

Es ist nicht erforderlich, die Rezepte im HaikuPorts-Repository zu halten. Man kann ein weiteres Repository erstellen, die Rezepte dort ablegen und anschließend haikuporter darauf verweisen.

Genau das, was ich brauche — es sei denn, ich suche nach einer Möglichkeit, das Paket öffentlich bereitzustellen. Aber das ist ein Thema für einen anderen Beitrag.

Installation von haikuporter und haikuports

cd \/boot\/home\/\ngit clone https:\/\/github.com\/haikuports\/haikuporter --depth=50\ngit clone https:\/\/github.com\/haikuports\/haikuports --depth=50\nln -s \/boot\/home\/haikuporter\/haikuporter \/boot\/home\/config\/non-packaged\/bin\/ # macht es von überall ausführbar\ncd haikuporter\ncp haikuports-sample.conf \/boot\/home\/config\/settings\/haikuports.conf\nsed -i -e 's|\/@mydisk/haikuports|\/boot\/home\/haikuports|g' \/boot\/home\/config\/settings\/haikuports.conf

Schreiben eines Rezepts

SUMMARY="Demo QtQuick-Anwendung"\nDESCRIPTION="QtQuickApp ist eine Demoversion einer QtQuick-Anwendung zum Testen der Haiku-Portierung und -Paketierung"\nHOMEPAGE="https:\/\/github.com\/probonopd\/QtQuickApp"\nCOPYRIGHT="None"\nLICENSE="MIT"\nREVISION="1"\nSOURCE_URI="https:\/\/github.com\/probonopd\/QtQuickApp.git"\n#PATCHES=""\nARCHITECTURES="x86_64"\nPROVIDES="\n    QtQuickApp = $portVersion\n"\nREQUIRES="\n    haiku\n"\nBUILD_REQUIRES="\n    haiku_devel\n    cmd:qmake\n"BUILD()\n{\n    qmake .\n    make $jobArgs\n}INSTALL()\n{\n    make install\n}

Bau eines Rezepts

Ich speichere die Datei unter dem Namen QtQuickApp-1.0.recipe, bevor ich haikuporter -S .\/QuickApp-1.0.recipeausführe. Die Abhängigkeiten für alle Pakete im Repository haikuports, was einige Zeit dauert. Ich werde mir jetzt einen Kaffee holen.

Warum sollte diese Überprüfung auf meiner lokalen Maschine erfolgen und nicht zentral auf einem Server einmal für alle?

Laut Mr. Waddlesplash:

Wegen der Möglichkeit, jede Datei im Repository zu überschreiben 😉 Man könnte dies leicht optimieren, indem man die benötigten Informationen nur dann berechnet, wenn es nötig ist, da die letzten Änderungen relativ selten sind.

~\/QtQuickApp> haikuporter  QtQuickApp-1.0.recipe\nÜberprüfe, ob Abhängigkeitsinformationen aktualisiert werden müssen ...\nSuche nach veralteten Abhängigkeitsinformationen ...\nFehler: QtQuickApp nicht im Repository gefunden

Es gibt anscheinend keine gewöhnliche Rezeptdatei, die den Quellcode Ihrer Anwendung enthält. Man muss ihn im Repository im HaikuPorts-Format aufbewahren.

~/QtQuickApp> mv QtQuickApp-1.0.recipe ../haikuports/app-misc/QtQuickApp/
~/QtQuickApp> ../haikuport
~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe

Diese Tatsache macht den Build komplizierter. Es gefällt mir nicht besonders, aber ich denke, es ist notwendig, damit schließlich alle Open-Source-Software in HaikuPorts erscheint.

Ich erhalte Folgendes:

~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe
Prüfe, ob Abhängigkeitsinformationen aktualisiert werden müssen ...
        Aktualisiere Abhängigkeitsinformationen von QtQuickApp-1.0
Suche nach veralteten Abhängigkeitsinformationen ...
Fehler: QtQuickApp-1.0.recipe in Baum nicht gefunden.

Was ist los? Nach dem Lesen von IRC mache ich:

~/QtQuickApp> haikuporter -S QtQuickApp
Prüfe, ob Abhängigkeitsinformationen aktualisiert werden müssen ...
        Aktualisiere Abhängigkeitsinformationen von QtQuickApp-1.0
Suche nach veralteten Abhängigkeitsinformationen ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Herunterladen: https://github.com/probonopd/QtQuickApp.git ...
--2019-07-14 16:12:44--  https://github.com/probonopd/QtQuickApp.git
Auflösung von github.com... 140.82.118.3
Verbindung zu github.com|140.82.118.3|:443... verbunden.
HTTP-Anforderung gesendet, Warte auf Antwort... 301 Permanently Moved
Standort: https://github.com/probonopd/QtQuickApp [weiter]
--2019-07-14 16:12:45--  https://github.com/probonopd/QtQuickApp
Wiederverwendung der bestehenden Verbindung zu github.com:443.
HTTP-Anforderung gesendet, Warte auf Antwort... 200 OK
Länge: nicht spezifiziert [text/html]
Speichern unter: ‘/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git’
     0K .                                                     1.34M=0.06s
2019-07-14 16:12:45 (1.34 MB/s) - ‘/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git’ gespeichert [90094]
Prüfe die Prüfziffer von QtQuickApp.git
Warnung: ----- Prüfziffer-Vorlage -----
Warnung: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"
Warnung: -----------------------------
Fehler: Keine Prüfziffer in der Rezeptdatei gefunden!

Eine interessante Frage ist aufgetaucht. Wenn ich eine Prüfziffer in das Rezept einfüge, wird sie dann dem letzten Git-Commit für die kontinuierliche Integration entsprechen? (Der Entwickler bestätigt: „Es wird nichts herauskommen. Rezepte sind so gestaltet, dass sie relativ stabil sind“).

Zur Belustigung fügen sie in das Rezept ein:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Immer noch nicht zufrieden:

~/QtQuickApp> haikuporter -S QtQuickApp
Prüfe, ob Abhängigkeitsinformationen aktualisiert werden müssen ...
        Aktualisiere Abhängigkeitsinformationen von QtQuickApp-1.0
Suche nach veralteten Abhängigkeitsinformationen ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------
Überspringe den Download der Quelle für QtQuickApp.git
Prüfe die Prüfziffer von QtQuickApp.git
Entpacke die Quelle von QtQuickApp.git
Fehler: Nicht erkannter Archivtyp in der Datei /boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git

Warum ist das so? Es handelt sich doch um ein Git-Repository, der Code ist dort direkt, da muss nichts entpackt werden. Meiner Meinung nach sollte das Tool intelligent genug sein, um keinen Entpacker zu suchen, wenn es eine URL von GitHub hat.

Vielleicht funktioniert uri git://

SOURCE_URI="git://github.com/probonopd/QtQuickApp.git"

Jetzt beschwert es sich so:

Downloading: git://github.com/probonopd/QtQuickApp.git ...
Fehler: Das Herunterladen von unsicheren Quellen ist in haikuports.conf deaktiviert!

Hmmm, und warum ist alles so kompliziert, warum kann es nicht einfach «funktionieren»? Schließlich ist es nicht so selten, etwas von GitHub zu kompilieren. Ganz zu schweigen von Tools, die sofort funktionieren, ohne dass eine Konfiguration notwendig ist, oder wie ich es nenne: «Herumgebastel».

Vielleicht funktioniert es so:

SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"

Nein. Ich bekomme immer noch diesen seltsamen Fehler und mache wie hier beschrieben

sed -i -e 's|#ALLOW_UNSAFE_SOURCES|ALLOW_UNSAFE_SOURCES|g' /boot/home/config/settings/haikuports.conf

Ich komme ein Stück weiter, aber warum schreit es mich an (GitHub ist doch nicht unsicher!) und versucht immer noch, etwas zu entpacken.

Laut mr. waddlesplash:

Nun ja, der Grund ist der Wunsch, die Integrität der für die Kompilierung verwendeten Daten zu überprüfen. Eine Möglichkeit ist die Überprüfung der Prüfziffer des Archivs, aber man könnte natürlich auch einzelne Dateien hashen, was nicht umgesetzt wird, da das viel mehr Zeit in Anspruch nimmt. Das ist auch der Grund für die «Unsicherheit» von Git und anderen VCS. Höchstwahrscheinlich wird es immer so sein, da es recht einfach und oft schneller ist, ein Archiv auf GitHub zu erstellen. Und in Zukunft wird die Fehlermeldung möglicherweise nicht so laut sein... (wir führen keine Merges solcher Rezepte mehr in HaikuPorts durch).

~\/QtQuickApp> haikuporter -S QtQuickApp
Überprüfung, ob Abhängigkeitsinformationen aktualisiert werden müssen ...
Suche nach veralteten Abhängigkeitsinformationen ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Downloading: git+https://github.com/probonopd/QtQuickApp.git ...
Warnung: UNSICHERE QUELLEN SIND SCHLECHT UND SOLLTEN NICHT IN DER PRODUKTION VERWENDET WERDEN
Warnung: BITTE WECHSELN SIE SOFORT ZU EINEM STATIC ARCHIV-DOWNLOAD MIT PRÜFZUMMEN!
Klone in leeres Repository '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
Entpacken der Quelle von QtQuickApp.git
tar: /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0: Kann nicht geöffnet werden: Datei oder Verzeichnis nicht gefunden
tar: Fehler ist nicht wiederherstellbar: Beende jetzt
Befehl 'git archive HEAD | tar -x -C "/boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0"' gab einen Status ungleich null zurück 2

Aus alter Gewohnheit frage ich die netten Leute im Kanal #haiku im Netzwerk irc.freenode.net. Und wo wäre ich ohne sie? Nach einem Hinweis habe ich verstanden, dass ich Folgendes verwenden muss:

srcGitRev="d0769f53639eaffdcd070bddfb7113c04f2a0de8"
SOURCE_URI="https://github.com/probonopd/QtQuickApp/archive/$srcGitRev.tar.gz"
SOURCE_DIR="QtQuickApp-$srcGitRev"
CHECKSUM_SHA256="db8ab861cfec0ca201e9c7b6c0c9e5e828cb4e9e69d98e3714ce0369ba9d9522"

Gut, es wurde klar, was es macht — es lädt ein Archiv mit Quellcodes einer bestimmten Revision herunter. Aus meiner Sicht ist das dumm und nicht ganz das, was ich wollte, nämlich die letzte Revision vom Master-Branch herunterzuladen.

Einer der Entwickler erklärte es so:

Wir haben unser eigenes CI, daher wird alles, was in das Repository haikuports gestellt wird, für alle Benutzer verpackt, und wir wollen nicht riskieren, "alle letzten Versionen im Upstream" zu sammeln und auszuliefern.

Verstanden! Auf jeden Fall kam Folgendes heraus:

warte darauf, dass das Build-Paket QtQuickApp-1.0-1 aktiviert wird
warte darauf, dass das Build-Paket QtQuickApp-1.0-1 aktiviert wird
warte darauf, dass das Build-Paket QtQuickApp-1.0-1 aktiviert wird
warte darauf, dass das Build-Paket QtQuickApp-1.0-1 aktiviert wird
warte darauf, dass das Build-Paket QtQuickApp-1.0-1 aktiviert wird
(...)

Es wiederholt sich endlos. Offensichtlich ist das ein Fehler (gibt es einen Bericht? Ich habe keinen gefunden).

C haikuporter und Repository haikuports Es spiegelt nicht das Niveau "funktioniert einfach", aber als Entwickler gefallen mir einige Dinge in der Arbeit mit Haiku. Im Großen und Ganzen ähnelt es dem Open Build Service — einem Set von Werkzeugen zum Erstellen von Linux-Builds: äußerst leistungsfähig, mit einem systematischen Ansatz, aber übertrieben für meine kleine "Hallo Welt"-Anwendung.

Wieder, laut Mr. waddlesplash:

In der Tat ist HaikuPorter standardmäßig sehr streng (außerdem gibt es den Lint-Modus sowie den strengen Modus, die es noch strenger machen!), aber nur, weil er Pakete erstellt, die tatsächlich funktionieren, und nicht einfach nur Pakete erstellt. Daher beschwert er sich über nicht deklarierte Abhängigkeiten, nicht ordnungsgemäß importierte Bibliotheken, falsche Versionen usw. Ziel ist es, alle Probleme ohne Ausnahme zu erkennen, einschließlich zukünftiger, bevor der Benutzer davon erfährt (daher konnte avrdude nicht installiert werden, denn im Rezept war tatsächlich eine Abhängigkeit angegeben). Bibliotheken sind nicht einfach separate Pakete und auch nicht bestimmte Versionen von SO. HaikuPorter achtet auf die Einhaltung all dessen in den Rezepten, um Laufzeitfehler zu vermeiden.

Im Prinzip ist dieses Maß an Strenge für die Erstellung eines Betriebssystems gerechtfertigt, aber ich halte es für übertrieben für eine "Hallo Welt"-Anwendung. Ich habe beschlossen, etwas anderes auszuprobieren.

Anwendungen im hpkg-Format erstellen mit dem Befehl „package create“

Vielleicht, dies eine einfache Anleitung wäre mir lieber?

mkdir -p apps/
cp QtQuickApp apps/cat >  .PackageInfo <<EOF
name QtQuickApp
version 1.0-1
architecture x86_64

summary "Demo QtQuick-Anwendung"
description "QtQuickApp ist eine Demo QtQuick-Anwendung zum Testen der Haiku-Portierung und -Verpackung"

packager "probono"
vendor "probono"

copyrights "probono"
licenses "MIT"

provides {
  QtQuickApp = 1.0-1
}requires {
  qt5
}
EOFpackage create -b QtQuickApp.hpkg
package add QtQuickApp.hpkg apps# Siehe unten, wenn Sie auch möchten, dass die Anwendung
# im Menü angezeigt wird.

Überraschend schnell, überraschend einfach, überraschend effektiv. Genau so, wie ich es mag, fantastisch!

Installation - was und wohin?

Ich habe die Datei QtQuickApp.hpkg verschoben nach ~ / config / packages, indem ich den Dateimanager verwendet habe, danach erschien QtQuickApp magisch in ~ / config / apps.
Wieder überraschend schnell, einfach und effektiv. Fantastisch, unglaublich!

Aber… (wohin ohne sie!)

Die Anwendung fehlt weiterhin in der Liste der Anwendungen im Menü und im QuickLaunch. Ich glaube, ich weiß schon, wie ich das beheben kann. Ich verschiebe QtQuickApp.hpkg im Dateimanager von ~ / config / packages nach / system / packages.

Nö, immer noch nicht vorhanden. Offensichtlich habe ich (nun, und die Anleitung) etwas übersehen.

Nachdem ich den Reiter «Inhalt» in HaikuDepot für einige andere Anwendungen angesehen habe, habe ich gesehen, dass es Dateien vom Typ /data/mimedb/application/x-vnd... was noch bemerkenswerter ist, /data/deskbar/menu/Applications/….

Was soll ich da reinpacken? Mal sehen…

mkdir -p data / deskbar / menu / Applications /
( cd data / deskbar / menu / Applications ; ln -s .. / .. / .. / .. / apps / QtQuickApp . )
package add QtQuickApp.hpkg apps data

Ich bin mir ziemlich sicher, dass dieser Trick funktionieren wird, aber es bleiben Fragen: Warum ist das notwendig, wofür ist es notwendig? Meiner Meinung nach zerstört es den Gesamteindruck, dass das System - so raffiniert ist.

Wie mr. waddlesplash erklärte:

Manchmal gibt es Anwendungen, die für andere Anwendungen erforderlich sind, aber nicht im Menü. Zum Beispiel der LegacyPackageInstaller in Ihrem Screenshot, der .pkg-Archive im BeOS-Format verarbeitet. Man möchte, dass die Benutzer diese installieren, aber eine Präsenz im Menü würde zu Verwirrung führen.

Ich habe das Gefühl, dass es eine einfachere Lösung gibt, z. B. Hidden=true in Dateien .desktop unter Linux. Warum nicht die „verborgenen“ Informationen zu einer Ressource und einem Dateisystemattribut machen?

Was besonders unausgereift ist - der Name (einer) Anwendung, die das Menü anzeigt, deskbar, ist fest in den Pfad eingebettet.

mr. waddlesplash erklärt dazu:

„Deskbar“ ist in diesem Fall als ein allgemeiner Begriff zu verstehen (ähnlich wie „taskbar“, das sowohl für eine Windows-Anwendung als auch für ein allgemeines Konzept verwendet wird). Nun, da es sich um deskbar, und nicht „Deskbar“ handelt, kann dies ebenfalls ähnlich verstanden werden.

2 „fast identische“ Verzeichnisse mit Anwendungen darin

Warum gibt es 2 Kataloge mit Anwendungen, und warum ist meine QtQuickApplication in einem enthalten, im anderen jedoch nicht? (Das ist ja nicht nur ein Systemkatalog, sondern auch ein Benutzerkatalog, was mir persönlich klar wäre).
Ich bin wirklich verwirrt und denke, dass es sinnvoll wäre, das zu vereinheitlichen.

Kommentar von mr. waddlesplash

Im Katalog Apps gibt es Anwendungen, die im Menü nicht benötigt werden. Aber die Situation mit dem Menü sollte wirklich verbessert werden, um es anpassbarer zu machen.

Antrag, oder das wird nicht passieren 😉

Ich habe darüber nachgedacht: Ist es wirklich notwendig, Anwendungen in /system/apps, zu platzieren, wenn die Benutzer sie dort nicht sehen sollten? Vielleicht wäre es besser, sie an einem anderen Ort zu platzieren, wo der Benutzer nicht mit ihnen in Berührung kommt? Genauso wie es in Mac OS X gemacht wird, wo der Inhalt der Pakete .app, der für den Benutzer nicht sichtbar sein sollte in /Applications, in den Tiefen von /System/Library/... versteckt wird.

Was ist mit den Abhängigkeiten?

Ich denke, es wäre sinnvoll, irgendwie auf die Abhängigkeiten hinzuweisen, oder? Kann Qt als fester Bestandteil der Haiku-Installation standardmäßig angesehen werden? Nein! Qt ist standardmäßig nicht installiert. Kann das Paketbau-Programm die Abhängigkeiten automatisch bestimmen, indem es die ELF-Dateien überprüft? Mir wurde gesagt, dass HaikuPorter das tatsächlich so macht, aber package nicht. Das liegt daran, dass es sich einfach um einen "Paketbauer" handelt, der einfach Dateien erstellt. hpkg.

Sollte Haiku verfeinert werden, indem eine Richtlinie eingeführt wird, die besagt, dass ein Paket keine Abhängigkeiten von Paketen haben darf, die nicht in haikuports? (Мне бы так хотелось, поскольку подобная политика значительно облегчает задачу — система смогла бы автоматически разрешить зависимости каждого пакета, загружаемого откуда угодно, без возни с дополнительными источниками пакетов).

mr. waddlesplash erklärt:

Wir würden den Entwicklern nicht so sehr die Freiheit nehmen wollen, denn es ist offensichtlich, dass wenn CompanyX sein eigenes Software-Paket mit Abhängigkeiten unterstützen möchte (und somit auch ein Repository) — sie dies völlig frei tun können.

In diesem Fall wäre es vielleicht sinnvoll, Drittanbieter-Pakete zu empfehlen, keine Abhängigkeiten von etwas außerhalb von haikuports zu haben, indem man alles Notwendige vollständig mit der Anwendung verpackt. Aber ich denke, das ist ein Thema für einen zukünftigen Artikel in dieser Serie. [Leitet der Autor auf AppImage hin? — Anmerkung des Übersetzers]

Hinzufügen eines Anwendungsicons

Und was ist, wenn ich eines der hübschen vorinstallierten Icons zu den Ressourcen meiner neu erstellten Anwendung hinzufügen möchte? Es stellt sich heraus, dass dies ein faszinierendes Thema ist, sodass es der Schwerpunkt des nächsten Artikels werden wird.

Wie organisiert man eine kontinuierliche Anwendungsentwicklung?

Stellen Sie sich ein Projekt vor, das Inkscape ähnlich ist (ja, ich bin mir bewusst, dass es bisher nicht in Haiku verfügbar ist, aber es ist bequem, es zu zeigen). Sie haben ein Repository für den Quellcode. https://gitlab.com/inkscape/inkscape.
Jedes Mal, wenn jemand seine Änderungen im Repository festschreibt, werden Build-Pipelines gestartet, nach denen die Änderungen automatisch getestet, kompiliert und die Anwendung in verschiedene Pakete verpackt wird, einschließlich AppImage für Linux (einem eigenständigen Anwendungsbundle, das heruntergeladen werden kann, um lokal getestet zu werden, unabhängig davon, was in dem System installiert ist oder nicht). [ich wusste es! — Anmerkung des Übersetzers]). Ähnlich passiert es bei jeder Anfrage zur Zusammenführung von Branches, sodass Sie die Anwendung, die aus dem im Merge-Antrag vorgeschlagenen Code erstellt wurde, noch vor der Zusammenführung herunterladen können.

Merge-Anfragen mit Build-Status und der Möglichkeit, die kompilierten Binärdateien im Falle eines erfolgreichen Builds herunterzuladen (grün markiert).

Der Build wird in Docker-Containern ausgeführt. GitLab bietet kostenlose Runner auf Linux an, zudem glaube ich, dass es möglich ist, eigene Runner zu verbinden (übrigens kann ich mir nicht vorstellen, wie das für Systeme wie Haiku funktioniert, von denen ich weiß, dass sie kein Docker oder ein Äquivalent haben, aber auch für FreeBSD gibt es kein Docker, sodass dieses Problem nicht einzigartig für Haiku ist).

Idealerweise könnte der Build von Anwendungen für Haiku innerhalb eines Docker-Containers für Linux durchgeführt werden. In diesem Fall könnte der Build für Haiku in bestehende Pipelines integriert werden. Gibt es Cross-Compiler? Oder muss man ganz Haiku innerhalb eines Docker-Containers emulieren, unter Verwendung von etwas wie QEMU/KVM (vorausgesetzt, es funktioniert so innerhalb von Docker)? Übrigens verwenden viele Projekte ähnliche Prinzipien. Zum Beispiel handelt es sich bei Scribus so — es ist bereits für Haiku verfügbar. Eines Tages wird der Moment kommen, an dem ich solche Anfragen zur Zusammenführung in andere Projekte senden kann, um ihnen Unterstützung für Haiku hinzuzufügen.

Einer der Entwickler erklärt:

Für andere Projekte, die Pakete selbst erstellen möchten, wird die übliche Methode CMake/CPack unterstützt. Andere Build-Systeme könnten unterstützt werden, wenn das Paketbauprogramm direkt aufgerufen wird, was gut ist, wenn die Leute daran interessiert sind. Die Erfahrung zeigt: Bisher gab es nicht besonderes Interesse, sodass haikuporter so arbeitete, wie es uns passte, aber letztendlich sollten beide Methoden zusammenarbeiten. Wir sollten ein Set von Werkzeugen für das Cross-Building von Software aus Linux oder jedem anderen Server-Betriebssystem bereitstellen (Haiku ist nicht für den Betrieb auf Servern gedacht).

Ich applaudierte stehend. Normale Linux-Benutzer tragen die ganze zusätzliche Last und das zusätzliche Gepäck (Sicherheit, strenge Kontrollen usw.), die für ein Server-Betriebssystem notwendig sind, aber nicht für ein persönliches. Daher stimme ich voll und ganz zu, dass die Möglichkeit, Anwendungen für Haiku unter Linux zu bauen, der richtige Weg ist.

Fazit

Das Portieren von POSIX-Anwendungen nach Haiku ist möglich, kann aber mehr Aufwand erfordern als ein gewöhnliches Neubauen. Ich würde mich definitiv länger damit beschäftigen, wenn nicht die Hilfe von Leuten aus dem Kanal #haiku im Netzwerk irc.freenode.net gewesen wäre. Aber selbst sie sahen nicht immer sofort, was nicht stimmte.

Anwendungen, die in Qt geschrieben sind, sind eine Ausnahme. Ich habe eine einfache Demoversion ohne besondere Probleme erstellt.

Das Erstellen von Paketen für einfache Anwendungen ist ebenfalls recht einfach, jedoch nur für „traditionell veröffentlichte“, d.h. für die in haikuports unterstützten versionierten Quellarchive. Für Continuous Builds (Bau bei jedem Commit) von GitHub ist alles nicht so einfach. Hier fühlt sich Haiku mehr wie eine Linux-Distribution an, als wie das Ergebnis auf Mac, wo man mit einem Klick auf „Bauen“ in XCode ein Paket erhält, .appdas bereit ist, in das Disk-Image integriert zu werden. .dmgbereit, auf meiner Website hochgeladen zu werden.
Continuous Builds für Anwendungen auf Basis eines „Server“-Betriebssystems, z.B. Linux, werden wahrscheinlich möglich, wenn es eine Nachfrage von Entwicklern gibt, aber im Moment hat das Haiku-Projekt andere, dringendere Aufgaben.

Probieren Sie es selbst aus! Das Haiku-Projekt bietet Images zum Herunterladen von DVD oder USB, die täglich erstellt werden. täglich.. Um es zu installieren, müssen Sie nur das Image herunterladen und es mit Etcher

Fragen? Wir laden Sie in den russischsprachigen Telegram-Kanal ein..

Fehlerübersicht: Wie man sich selbst in C und C++ ins Bein schießt. Eine Sammlung von Rezepten für Haiku OS

Von Autor Übersetzung: Dies ist der fünfte Artikel aus einer Reihe über Haiku.

Artikelübersicht: Erster Zweiter Dritte Vierter

Quelle: habr.com