🥇Mein fünfter Tag mit Haiku: Lassen Sie uns ein paar Programme portieren

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

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

Vor kurzem 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 mit dem Wechsel zu Haiku aus der Sicht eines Linux-Entwicklers. Ich bitte um Entschuldigung für dumme Fehler, die ich im Prozess gemacht habe, denn es ist noch keine Woche vergangen, seit ich Haiku zum ersten Mal heruntergeladen habe.

Ich möchte drei Ziele erreichen:

Ein einfaches CLI-Programm portieren.
Eine GUI-Anwendung auf Qt portieren.
Diese später im hpkg-Format verpacken (da ich noch über die Anpassung von AppDir und AppImage für Haiku nachdenke …).

Lassen Sie uns beginnen. In den Abschnitten Dokumentation und Entwicklung, sowie im Wiki von HaikuPorts fand ich die richtige Richtung. Es gibt sogar ein Online-PDF-Buch. BeOS: Portierung von Unix-Anwendungen..
467 Seiten – und das seit 1997! Es ist beängstigend, einen Blick hineinzuwerfen, aber ich hoffe auf das Beste. Die Worte des Entwicklers sind ermutigend: „Es dauert lange, weil BeOS nicht POSIX-kompatibel war“, aber Haiku ist „größtenteils“ schon so.

Portierung einer einfachen CLI-Anwendung.

Der erste Gedanke war, eine Anwendung zu portieren. avrdude, aber wie sich herausstellt, ist das bereits die Möglichkeit geschaffen, Linux-Betriebssysteme mit dem Steuerpanel ISPmanager 5 Lite zu installieren. lange her.

Erster Versuch: nichts zu sehen

Was ich einfach nicht verstehen kann, ist, dass bereits seit über 10 Jahren Anwendungen für Haiku portiert werden — obwohl das Betriebssystem noch nicht einmal die Version 1.0 erreicht hat.

Zweiter Versuch: muss neu geschrieben werden

Also werde ich ptouch-770, CLI zur Verwaltung des Brother P-Touch 770-Druckers, auf dem ich Etiketten drucke.
Ich drucke verschiedene Etiketten damit, und Sie haben ihn möglicherweise schon im letzten Artikel gesehen. Vor einigen Tagen schrieb ich ein kleines Wrapper-Programm mit GUI in Python (da es auf Gtk+ basiert — muss ich das neu schreiben, und das ist eine gute Gelegenheit, um dazuzulernen).

Brother P-Touch 770 Etikettendrucker. Wird er unter Haiku funktionieren?

Der Haiku-Paketmanager kennt die Bibliotheken und Befehle, also wenn ich die Meldung „can’t find libintl“ beim Start erhalte, configure starte ich einfach pkgman install devel:libintl und das benötigte Paket wird gefunden. Ähnlich pkgman install cmd:rsync. Nun, usw.

Es sei denn, es funktioniert nicht:

/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

Möglicherweise ist udev zu linux-like, weshalb es nicht für Haiku existiert. Das bedeutet, dass ich den Quellcode, den ich versuche zu kompilieren, anpassen muss.
Tja, ich kann nicht höher springen, als ich kann, und ich weiß nicht einmal, wo ich anfangen soll.

Dritter Versuch

Es wäre großartig, zu haben tmate für Haiku, dann würde ich den Entwicklern von Haiku erlauben, sich mit meiner Terminalsitzung zu verbinden — für den Fall, dass etwas schiefgeht. Die Anweisungen sind ziemlich einfach:

./autogen.sh
./configure
make
make install

Sieht gut aus, also warum nicht ausprobieren auf Haiku?

/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 diesem Punkt öffne ich HaikuDepot und suche nach curses.
Ich habe etwas gefunden, das mir einen Hinweis für eine präzisere 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 ging wieder zu HaikuDepot und fand natürlich devel:msgpack_c_cpp_devel. Was sind das 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 die Portierung eines Programms nach Haiku erheblich mehr Wissen erfordert, als nur eine einfache Neukompilierung.
Ich sprach mit den freundlichen Entwicklern von Haiku, und es stellte sich heraus, dass es einen Fehler in msgpack gab. Nach ein paar Minuten sehe ich den Patch in HaikuPorts. Ich beobachte, wie das korrigierte Paket hier gebaut wird (buildslave — virtuelle Maschinen).

Bau des korrigierten msgpack auf dem buildmaster

Ich sende nebenbei den Patch upstream um Unterstützung für 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 kehre 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 aus:

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

Das Ergebnis:

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

Na toll, wieder… Übrigens:

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

mr. waddlesplash zeigt an, wo man graben sollte:

/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 config.log.

Mir wurde erklärt, dass es zu libresolv unter Haiku noch etwas in libnetwork gibt. Offenbar muss der Code weiter bearbeitet werden. Ich muss nachdenken…

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

Die ewige Frage: Was passiert hier eigentlich.

/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 spezifischer. Hab gegoogelt und diese gefunden.. Wenn ich hinzufüge -lssp hilft es „manchmal“, ich probiere es:

/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 es 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 nicht stimmt und wie man das beheben kann? Falls ja, werde ich den Artikel aktualisieren. Link zu GitHub.

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. Unter einer Minute!

Verpackung von Anwendungen in hpkg mit haikuporter und haikuports.

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

Der Befehl Paket — eine grundlegende Methode zur Erstellung von Paketen. In den meisten Fällen ist PackageInfo ausreichend, wie im Abschnitt „Making it into a proper .hpkg package“ beschrieben.
Ich muss etwas tun. solches
Es kann verwendet werden hpkg-creator (es stürzt bei mir ab, Fehlerbericht)

Es ist unklar, was zu tun ist. Ich nehme an, ich brauche ein Anfängerhandbuch im Stil von „Hallo, Welt!“, idealerweise ein Video. Es wäre auch hilfreich, eine benutzerfreundliche Einführung in HaikuPorter zu bekommen, ähnlich wie bei GNU hello.

Ich lese Folgendes:

haikuporter ist ein Tool zur Erstellung allgemeiner Paketprojekte für Haiku. Es verwendet das HaikuPorts-Repository als Grundlage für alle Pakete. Für die Erstellung von Paketen werden Rezepte von haikuporter verwendet.

Zusätzlich erfahre ich, dass:

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

Genau das, was ich brauche – es sei denn, ich suche nach einer Möglichkeit zur öffentlichen Bereitstellung des Pakets. Aber das ist ein Thema für einen anderen Beitrag.

Installation von haikuporter und haikuports

cd /boot/home/
git clone https://github.com/haikuports/haikuporter --depth=50
git clone https://github.com/haikuports/haikuports --depth=50
ln -s /boot/home/haikuporter/haikuporter /boot/home/config/non-packaged/bin/ # damit es von überall ausführbar ist
cd haikuporter
cp haikuports-sample.conf /boot/home/config/settings/haikuports.conf
sed -i -e 's|/mydisk/haikuports|/boot/home/haikuports|g' /boot/home/config/settings/haikuports.conf

Rezeptverfassung

SUMMARY="Demo QtQuick Anwendung"
DESCRIPTION="QtQuickApp ist eine Demo QtQuick Anwendung zum Testen des Haiku Portierens und Packens"
HOMEPAGE="https://github.com/probonopd/QtQuickApp"
COPYRIGHT="Keine"
LICENSE="MIT"
REVISION="1"
SOURCE_URI="https://github.com/probonopd/QtQuickApp.git"
#PATCHES=""
ARCHITECTURES="x86_64"
PROVIDES="
    QtQuickApp = $portVersion
"
REQUIRES="
    haiku
"
BUILD_REQUIRES="
    haiku_devel
    cmd:qmake
"BUILD()
{
    qmake .
    make $jobArgs
}INSTALL()
{
    make install
}

Rezeptkompilierung

Speichere die Datei unter dem Namen QtQuickApp-1.0.recipe, danach starte ich aikuporter -S ./QuickApp-1.0.recipe. Überprüfe die Abhängigkeiten für alle Pakete im Repository haikuports, was einige Zeit in Anspruch nimmt. Ich gehe mir eine Tasse Kaffee holen.

Warum sollte diese Überprüfung auf meinem lokalen Rechner und nicht zentral auf dem Server für alle durchgeführt werden?

Laut Mr. waddlesplash:

Weil man jede Datei im Repository überschreiben kann 😉 Man könnte das ein wenig optimieren, indem man die benötigten Informationen bei Bedarf berechnet, da die zuletzt vorgenommenen Änderungen ziemlich selten sind.

~/QtQuickApp> haikuporter  QtQuickApp-1.0.recipe
Überprüfen, ob Abhängigkeitsinformationen aktualisiert werden müssen ...
Suche nach veralteten Abhängigkeitsinformationen ...
Fehler: QtQuickApp im Repository nicht gefunden

Es gibt offenbar keine normale Rezeptdatei, die den Quellcode Ihrer Anwendung enthält. Diese muss im Repository im HaikuPorts-Format aufbewahrt werden.

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

Diese Tatsache macht den Aufbau umständlicher. Das gefällt mir nicht so gut, aber ich denke, es ist notwendig, damit letztendlich alle Open-Source-Software in HaikuPorts verfügbar ist.

Ich erhalte Folgendes:

~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe
Überprüfen, ob Abhängigkeitsinformationen aktualisiert werden müssen ...
        Aktualisierung der Abhängigkeitsinfos von QtQuickApp-1.0
Suche nach veralteten Abhängigkeitsinformationen ...
Fehler: QtQuickApp-1.0.recipe nicht im Baum gefunden.

Was ist falsch? Nach dem Lesen im IRC mache ich:

~/QtQuickApp> haikuporter -S QtQuickApp
Überprüfen, ob Abhängigkeitsinformationen aktualisiert werden müssen ...
        Aktualisierung der 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-Anfrage gesendet, warte auf Antwort... 301 Dauerhaft verschoben
Standort: https://github.com/probonopd/QtQuickApp [weiter]
--2019-07-14 16:12:45--  https://github.com/probonopd/QtQuickApp
Bestehende Verbindung zu github.com:443 wiederverwenden.
HTTP-Anfrage gesendet, warte auf Antwort... 200 OK
Länge: nicht angegeben [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]
Überprüfung der Prüfziffer von QtQuickApp.git
Warnung: ----- PRÜFZIFERTAUSCH -----
Warnung: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"
Warnung: -----------------------------
Fehler: Keine Prüfziffer im Rezept gefunden!

Eine interessante Frage hat sich ergeben. Wenn ich eine Prüfziffer in das Rezept einfüge – wird sie mit dem letzten Git-Commit für die kontinuierliche Integration übereinstimmen? (Der Entwickler bestätigt: „Es wird nichts passieren. Rezepte sind so konzipiert, dass sie relativ stabil sind.“)

Zur Veranschaulichung hinzufügen:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Immer noch unzufrieden:

~/QtQuickApp> haikuporter -S QtQuickApp
Überprü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
Validiere die Prüfziffer von QtQuickApp.git
Entpacke die Quelle von QtQuickApp.git
Fehler: Nicht erkannter Archivtyp in Datei /boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git

Wieso das? Es ist schließlich ein Git-Repository, der Code ist bereits dort, da gibt es nichts zu entpacken. Meiner Meinung nach sollte das Tool intelligent genug sein, um keinen Entpacker zu suchen, wenn es sich um eine URL von GitHub handelt.

Vielleicht funktioniert es mit uri git://

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

Jetzt beschwert es sich so:

Herunterladen: 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 kommt es nicht so selten vor, dass man etwas von GitHub herunterladen kann. Es geht um Tools, die sofort funktionieren, ohne die Notwendigkeit einer Konfiguration oder wie ich es nenne, "herumzupfuschen".

Vielleicht funktioniert es so:

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

Nein. Ich bekomme immer noch diesen merkwürdigen 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 kleines Stück weiter, aber warum schreit es mich an (GitHub ist doch nicht sicher!) und versucht weiterhin, irgendetwas zu entpacken?

Laut mr. waddlesplash:

Ja, der Grund ist der Wunsch, die Integrität der für den Build erhaltenen Daten zu überprüfen. Eine Möglichkeit besteht darin, die Prüfziffer des Archivs zu überprüfen, aber man könnte natürlich auch einzelne Dateien hashieren, was nicht umgesetzt wird, da dies viel mehr Zeit in Anspruch nimmt. Dies führt auch zur 'Unsicherheit' von git und anderen VCS. Wahrscheinlich wird das immer so sein, da es relativ einfach und oft schneller ist, ein Archiv auf GitHub zu erstellen. In Zukunft könnte die Fehlermeldung vielleicht nicht mehr so laut sein… (wir führen keine Zusammenführungen solcher Rezepte in HaikuPorts mehr durch).

~/QtQuickApp> haikuporter -S QtQuickApp
Überprüfung, ob Änderungen der Abhängigkeiten aktualisiert werden müssen ...
Suche nach veralteten Abhängigkeiten ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Herunterladen: git+https://github.com/probonopd/QtQuickApp.git ...
Warnung: UNSICHERE QUELLEN SIND SCHLECHT UND SOLLTEN NICHT IN PRODUKTION VERWENDET WERDEN
Warnung: BITTE WECHSELN SIE SOFORT ZU EINEM STATISCHEN ARCHIV-DOWNLOAD MIT CHECKSUM!
Klonen in das leere 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 kann nicht behoben werden: beende jetzt
Befehl 'git archive HEAD | tar -x -C "/boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0"' gab einen nicht nullen Exit-Status 2 zurück

Alt gewohnt, frage ich gute Leute im Kanal #haiku im Netzwerk irc.freenode.net. Und wo wäre ich ohne sie? Nach dem Hinweis habe ich verstanden, dass ich verwenden muss:

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

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

Einer der Entwickler erklärte es so:

Wir haben unser eigenes CI, sodass alles, was in das Repository haikuports eingeht, für alle Benutzer paketiert wird, und wir wollen kein Risiko eingehen, indem wir "die neuesten Versionen aus dem Upstream" bauen und liefern.

Verstanden! Auf jeden Fall gab es folgendes Ergebnis:

warte auf die Aktivierung des Paketbaus QtQuickApp-1.0-1
warte auf die Aktivierung des Paketbaus QtQuickApp-1.0-1
warte auf die Aktivierung des Paketbaus QtQuickApp-1.0-1
warte auf die Aktivierung des Paketbaus QtQuickApp-1.0-1
warte auf die Aktivierung des Paketbaus QtQuickApp-1.0-1
(...)

Es wiederholt sich endlos. Das scheint ein Fehler zu sein (gibt es eine Anfrage? Ich habe keine gefunden).

E haikuporter und dem Repository haikuports Es fühlt sich nicht so an, als würde es einfach funktionieren, aber als Entwickler gefallen mir einige Dinge an der Arbeit mit Haiku. Insgesamt ähnelt es dem Open Build Service — einem Werkzeugsetz für die Erstellung von Linux-Bauten: äußerst leistungsfähig, mit einem systematischen Ansatz, aber übertrieben für meine kleine Anwendung auf "hello world"-Ebene.

Again, according to Mr. waddlesplash:

In der Tat ist HaikuPorter standardmäßig sehr streng (außerdem gibt es den Lint-Modus und den strengen Modus, die es noch strenger machen!), aber das liegt nur daran, dass er Pakete erstellt, die tatsächlich funktionieren, anstatt nur irgendwelche Pakete zu generieren. Deshalb beschwert er sich über nicht erklärte Abhängigkeiten, nicht ordnungsgemäß importierte Bibliotheken, falsche Versionen usw. Das Ziel ist es, alle Probleme ohne Ausnahme zu erfassen, einschließlich zukünftiger, bevor der Benutzer davon erfährt (deshalb konnte avrdude nicht installiert werden, da im Rezept tatsächlich eine Abhängigkeit angegeben war). Bibliotheken sind nicht einfach separate Pakete und auch keine bestimmten Versionen von SO. HaikuPorter stellt sicher, dass all dies in den Rezepten eingehalten wird, um Laufzeitfehler zu vermeiden.

Im Grunde ist ein solcher Grad an Strenge bei der Erstellung eines Betriebssystems gerechtfertigt, aber ich halte ihn für übertrieben für eine "Hello World"-Anwendung. Ich habe beschlossen, etwas anderes auszuprobieren.

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

Vielleicht, diesem würde eine einfache Anleitung mir besser gefallen?

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 Demoversion einer QtQuick-Anwendung zur Überprüfung der Portierung und Verpackung für Haiku"

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 die Anwendung auch im Menü anzeigen möchten

Unerwartet schnell, unerwartet einfach, unerwartet effizient. Genau so, wie ich es mag, beeindruckend!

Installation – was und wo?

Ich habe die Datei QtQuickApp.hpkg verschoben nach ~/config/packages, indem ich den Dateimanager verwendet habe, danach erschien QtQuickApp magisch in ~/config/apps.
Erneut unerwartet schnell, einfach und effizient. Einfach fantastisch, unglaublich!

Aber… (wohin ohne sie!)

Die Anwendung fehlt weiterhin in der Liste des Anwendungsmenüs und in QuickLaunch. Ich glaube, ich weiß, wie ich das beheben kann. Im Dateimanager bewege ich QtQuickApp.hpkg von ~/config/packages nach /system/packages.

Nein, immer noch nicht vorhanden. Offensichtlich habe ich (naja, und die Anleitung) etwas übersehen.

Als ich die Registerkarte „Inhalte“ in HaikuDepot für einige andere Anwendungen durchblätterte, bemerkte ich, dass es Dateien vom Typ gab /data/mimedb/application/x-vnd... was noch bemerkenswerter ist, /data/deskbar/menu/Applications/….

Also, was soll ich dort hineinlegen? 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 funktioniert, aber ich habe noch Fragen: Warum ist das nötig, wofür wird es gebraucht? Meiner Meinung nach beeinträchtigt das den Gesamteindruck, dass das System so raffiniert ist.

Wie Mr. Waddlesplash erklärte:

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

Irgendwie habe ich das Gefühl, dass es eine einfachere Lösung gibt, zum Beispiel Hidden=true in den Dateien .desktop unter Linux. Warum nicht die „versteckten“ Informationen als Ressource und Attribut des Dateisystems behandeln?

Was besonders wenig raffiniert ist – der Name (einer) Anwendung, die das Menü anzeigt, deskbar, ist fest im Pfad verankert.

Mr. Waddlesplash erklärt dies wie folgt:

„Deskbar“ sollte in diesem Fall als ein allgemeiner Begriff verstanden werden (ähnlich wie „taskbar“, das sowohl für die Windows-Anwendung als auch für das allgemeine Konzept steht). Da dies deskbar, und nicht „Deskbar“, kann man es ebenfalls ähnlich interpretieren.

2 „fast identische“ Kataloge mit den darin enthaltenen Anwendungen

Warum gibt es 2 Kataloge mit Anwendungen und warum gibt es in einem meinen QtQuickApplication und im anderen nicht? (Das ist doch kein einfacher Systemkatalog, sondern ein zweiter Benutzerkatalog, was mir persönlich einleuchtet).
Ich bin wirklich verwirrt und denke, dass wir das vereinheitlichen sollten.

Kommentar von mr. waddlesplash

Im Katalog Apps gibt es Anwendungen, die im Menü nicht benötigt werden. Aber die Situation im Menü muss wirklich verbessert werden, um es anpassungsfähiger zu machen.

Anfrage, oder das wird nicht passieren 😉

Ich habe darüber nachgedacht: Ist es wirklich notwendig, Anwendungen in /system/apps, wenn es für die Benutzer unerwünscht ist, sie dort zu sehen? Vielleicht sollten wir sie woanders unterbringen, wo die Benutzer nicht damit konfrontiert werden? So wie es in Mac OS X gemacht wird, wo der Inhalt der Pakete .app, der für den Benutzer nicht sichtbar sein sollte, in den Tiefen /System/Library/… versteckt wird. /ApplicationsWas ist mit den Abhängigkeiten?

Wie steht es um Abhängigkeiten?

Ich denke, es wäre sinnvoll, die Abhängigkeiten zu erläutern, oder? Kann man Qt als Teil der standardmäßigen Haiku-Installation betrachten? Leider nicht! Qt ist standardmäßig nicht installiert. Kann das Paketbausystem Abhängigkeiten automatisch identifizieren, indem es die ELF-Dateien prüft? Mir wurde gesagt, dass HaikuPorter das tatsächlich tut, aber Paket nein. Das liegt daran, dass es sich einfach um einen "Paketbauer" handelt, der allein die Dateien erstellt. hpkg.

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

mr. waddlesplash erklärt:

Wir möchten die Freiheit der Entwickler nicht zu sehr einschränken, denn es ist offensichtlich, dass wenn CompanyX ihre eigene Software-Suite mit Abhängigkeiten unterstützen möchte (und damit auch ein Repository) – sie dies völlig frei tun kann.

In diesem Fall wäre es vielleicht ratsam, Drittanbieter-Pakete zu vermeiden, die von etwas abhängen, das nicht in haikuports enthalten ist, 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. [Zielt der Autor auf AppImage ab? — Anmerkung des Übersetzers]

Hinzufügen des Anwendungssymbols

Was ist, wenn ich meinem neu erstellten Anwendung Ressourcen eines der schönen integrierten Icons hinzufügen möchte? Es stellt sich heraus, dass dies ein faszinierendes Thema ist, das die Grundlage für den nächsten Artikel bildet.

Wie organisiert man eine kontinuierliche Anwendungserstellung?

Stellen Sie sich ein Projekt wie Inkscape vor (ja, ich weiß, dass es noch nicht in Haiku verfügbar ist, aber es ist praktisch zur Darstellung). Sie haben ein Quellcode-Repository. https://gitlab.com/inkscape/inkscape.
Jedes Mal, wenn jemand seine Änderungen ins Repository einpflegt, werden Build-Pipelines ausgelöst, die Änderungen werden automatisch getestet, die Anwendung wird in verschiedene Pakete geschnürt, einschließlich AppImage für Linux (ein autonomes Anwendungs-Paket, das zum lokalen Testen heruntergeladen werden kann, unabhängig davon, was in das System installiert werden kann oder nicht). [ich wusste es! — Anm. d. Übersetzers]). Dasselbe geschieht bei jeder Anfrage zum Zusammenführen von Branches, sodass man die Anwendung, die aus dem Code der Merge-Anfrage erstellt wurde, schon vor dem Merging herunterladen kann.

Merge-Anfragen mit Build-Status und der Möglichkeit, bei erfolgreichem Build die generierten Binärdateien herunterzuladen (grün markiert)

Der Build wird in Docker-Containern gestartet. GitLab bietet kostenlose Runner für Linux an, und ich denke, es ist möglich, eigene Runner zu integrieren (übrigens habe ich keine Ahnung, wie das bei Systemen wie Haiku funktionieren wird, die, soweit ich weiß, keinen Docker oder ein Äquivalent haben, und für FreeBSD gibt es ebenfalls keinen Docker, sodass dieses Problem nicht einzigartig für Haiku ist).

Idealerweise könnte das Kompilieren von Anwendungen für Haiku innerhalb eines Docker-Containers für Linux erfolgen. In diesem Szenario könnte die Kompilierung für Haiku in bestehende Pipelines integriert werden. Gibt es Cross-Compiler? Oder muss man das gesamte Haiku innerhalb eines Docker-Containers emulieren, indem man etwas wie QEMU/KVM verwendet (vorausgesetzt, es funktioniert so innerhalb von Docker)? Übrigens nutzen viele Projekte ähnliche Prinzipien. Zum Beispiel macht Scribus das – es ist bereits für Haiku verfügbar. Eines Tages werde ich in der Lage sein, solche Merge-Anfragen in andere Projekte zu senden, um sie um Unterstützung für Haiku zu erweitern.

Einer der Entwickler erklärt:

Für andere Projekte, die ihre Pakete selbst erstellen möchten, wird die gängige Methode CMake/CPack unterstützt. Andere Build-Systeme können unterstützt werden, wenn das Paketbauteil direkt aufgerufen wird, was vorteilhaft ist, wenn das Interesse vorhanden ist. Die Erfahrung zeigt: Bisher gab es kaum Interesse, sodass haikuporter so funktioniert hat, wie es uns am besten passte. Letztendlich sollten jedoch beide Methoden zusammenarbeiten. Wir sollten ein Set von Werkzeugen für das Cross-Building von Software unter Linux oder einem anderen Serverbetriebssystem anbieten (Haiku ist nicht dafür gedacht, auf Servern betrieben zu werden).

Stehende Ovationen. Normale Linux-Nutzer tragen all diese Zusatzlast und den zusätzlichen Ballast (Sicherheit, strenger Kontrollen usw.), der für Serverbetriebssysteme notwendig ist, aber nicht für persönliche. Daher stimme ich vollkommen zu, dass die Möglichkeit, Anwendungen für Haiku unter Linux zu erstellen, der richtige Weg ist.

Fazit

Die Portierung von POSIX-Anwendungen auf Haiku ist möglich, kann jedoch mehr Aufwand erfordern als ein gewöhnlicher Neubau. Ich hätte mich sicher lange damit beschäftigt, wenn nicht die Unterstützung von Leuten im #haiku-Kanal im irc.freenode.net gewesen wäre. Aber selbst sie haben nicht immer sofort erkannt, was nicht stimmt.

Anwendungen, die mit Qt geschrieben sind, sind eine angenehme Ausnahme. Ich habe eine einfache Demoversion ohne größere Probleme erstellt.

Das Erstellen eines Pakets für einfache Anwendungen ist ebenfalls recht unkompliziert, aber nur für solche, die auf herkömmliche Weise veröffentlicht werden, d.h. für die versionierte Quellcodearchive zur Unterstützung in haikuports. Bei der kontinuierlichen Erstellung (Erstellung bei jedem Commit) von GitHub ist es jedoch nicht ganz so einfach. Hier fühlt sich Haiku eher wie eine Linux-Distribution an als wie das Ergebnis auf einem Mac, wo man durch einen Klick auf 'Bauen' in XCode ein Paket erhält, .app, das bereit ist, in das Disk-Image eingefügt zu werden, .dmg, das zum Hochladen auf meiner Website vorbereitet ist.
Die kontinuierliche Entwicklung von Anwendungen auf Basis eines „Server“-Betriebssystems, wie z. B. Linux, wird wahrscheinlich möglich, wenn eine Nachfrage von Entwicklern besteht. Momentan hat das Haiku-Projekt jedoch andere, dringendere Aufgaben.

Probieren Sie es selbst! Das Haiku-Projekt bietet ISO-Images zum Herunterladen von DVD oder USB, die täglich. Für die Installation genügt es, das Abbild herunterzuladen und mit Hilfe von Etcher

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

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

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

Artikelübersicht: Erster Die zweite Dritte Vierter

Quelle: habr.com