🥇Mein fünfter Tag mit Haiku: Lasst uns einige Programme portieren

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

Mein erstes portiertes Haiku-Programm, verpackt im HPKG-Format

Kürzlich Ich habe Haiku entdeckt, ein überraschend gutes Betriebssystem für PCs.
Heute werde ich lernen, wie man neue Programme auf dieses Betriebssystem portiert. Im Mittelpunkt steht die Beschreibung der ersten Erfahrungen beim Umstieg auf Haiku aus der Sicht eines Linux-Entwicklers. Ich entschuldige mich für alle dummen Fehler, die ich unterwegs gemacht habe, da es noch nicht einmal eine Woche her ist, seit ich Haiku zum ersten Mal heruntergeladen habe.

Ich möchte drei Ziele erreichen:

Portieren Sie eine einfache CLI-Anwendung
Portieren Sie eine Anwendung von der GUI nach Qt
Packen Sie sie dann im HPKG-Format (da ich immer noch darüber nachdenke, AppDir und AppImage für Haiku anzupassen ...)

Lass uns anfangen. Abschnittsweise Dokumentation и Entwicklungund so in Wiki Von HaikuPorts habe ich die richtige Richtung gefunden. Es gibt sogar ein Online-PDF-Buch BeOS: Portierung einer Unix-Anwendung.
467 Seiten – und das aus dem Jahr 1997! Es ist beängstigend, hineinzuschauen, aber ich hoffe das Beste. Die Worte des Entwicklers sind ermutigend: „Es hat lange gedauert, weil BeOS nicht POSIX-kompatibel war“, aber Haiku ist „größtenteils“ bereits so.

Portierung einer einfachen CLI-Anwendung

Der erste Gedanke war, die Anwendung zu portieren avrdude, aber wie sich herausstellte, ist dies bereits der Fall getan haben vor langer Zeit.

Erster Versuch: Nichts zu sehen

Was ich nicht verstehen kann, ist das schon Apps werden seit über 10 Jahren auf Haiku portiert - und das, obwohl das Betriebssystem selbst noch nicht einmal die Version 1.0 hat.

Zweiter Versuch: Muss neu geschrieben werden

Also werde ich verwenden ptouch-770, CLI zur Steuerung des Brother P-Touch 770-Druckers, den ich zum Drucken von Etiketten verwende.
Ich drucke darauf verschiedene Etiketten, die Sie vielleicht schon im vorherigen Artikel gesehen haben. Etwas früher habe ich ein kleines GUI-Wrapper-Programm in Python geschrieben (da es in Gtk+ ist, muss es neu geschrieben werden, und das ist ein guter Grund, es zu lernen).

Brother P-Touch 770 Etikettendrucker. Funktioniert er mit Haiku?

Der Haiku-Paketmanager kennt sich mit Bibliotheken und Befehlen aus, wenn ich also beim Ausführen die Meldung „libintl kann nicht gefunden werden“ erhalte configure - Ich starte einfach pkgman install devel:libintl und das benötigte Paket wird gefunden. Ebenfalls pkgman install cmd:rsync. Na ja, usw.

Außer wenn das nicht funktioniert:

/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-basiert und existiert daher für Haiku nicht. Das bedeutet, dass ich den Quellcode, den ich kompilieren möchte, bearbeiten muss.
Äh, du kannst nicht über deinen Kopf springen und ich weiß nicht einmal, wo ich anfangen soll.

Dritter Versuch

Es wäre schön, es zu haben tmate Für Haiku würde ich den Haiku-Entwicklern erlauben, sich mit meiner Terminalsitzung zu verbinden – für den Fall, dass etwas schief geht. Die Anleitung ist ganz einfach:

./autogen.sh
./configure
make
make install

Sieht gut aus, warum also nicht mal Haiku ausprobieren?

/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

In diesem Schritt öffne ich HaikuDepot und suche curses.
Es wurde etwas gefunden, das mir einen Hinweis für eine kompetentere Anfrage gab:

/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

Wieder ging ich zu HaikuDepot und wurde natürlich fündig 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

Bei diesem Schritt wurde mir klar, dass die Portierung eines Programms nach Haiku viel mehr Wissen erfordert, als für eine einfache Neuerstellung erforderlich ist.
Ich habe mit den freundlichen Haiku-Entwicklern gesprochen, es stellte sich heraus, dass es einen Fehler im msgpack gibt, und nach ein paar Minuten sehe ich einen Patch in HaikuPorts. Ich kann mit eigenen Augen sehen, wie das korrigierte Paket aussieht hierher gehen (Buildslave – virtuelle Maschinen).

Erstellen des korrigierten Msgpacks auf Buildmaster

Zwischendurch schicke ich einen Patch an den Upstream um Haiku-Unterstützung zu 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.

Unerwartet gut. Habe ich das gesagt?!

Ich komme zurück zum ursprünglichen Problem:

/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 sieht es so aus, als wäre msgpack nicht schuld. Ich kommentiere IMAXLABEL в tty.c wie folgt:

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

Ergebnis:

osdep-unknown.c: In function 'osdep_get_cwd':
osdep-unknown.c:32:19: warning: unused parameter 'fd' [-Wunused-parameter]
 osdep_get_cwd(int fd)
               ~~~~^~
make: *** No rule to make target 'compat/forkpty-unknown.c', needed by 'compat/forkpty-unknown.o'.  Stop.

Nun, es geht wieder los... Übrigens:

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

Herr. watschelnsplash sagt Ihnen, wo Sie graben müssen:

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

Sie erklärten mir, dass es in libnetwork neben libresolv noch etwas anderes auf Haiku gibt. Anscheinend muss der Code noch weiter bearbeitet werden. Denken sollten…

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

Die ewige Frage: Was ist los?

/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 im Profil. Gegoogelt und Ich habe es gefunden. Wenn Sie hinzufügen -lssp „Manchmal“ hilft, ich versuche:

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

Wow! Es fängt an! Aber…

[tmate] ssh.tmate.io lookup failure. Retrying in 2 seconds (non-recoverable failure in name resolution)

Ich werde versuchen zu debuggen Datei hier:

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

„Bad Port ID“ ist schon wie eine Visitenkarte Haiku. Vielleicht hat jemand eine Idee, was falsch ist und wie man es beheben kann? Wenn ja, werde ich den Artikel aktualisieren. Link zu GitHub.

Portierung der GUI-Anwendung nach 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!

Wirklich einfach. Weniger als einer Minute!

Verpacken von Anwendungen in HPKG mit Haikuporter und Haikuports.

Womit soll ich beginnen? Es gibt keine einfache Dokumentation, ich gehe zum #haiku-Kanal auf irc.freenode.net und höre:

Team package – eine Low-Level-Methode zum Erstellen von Paketen. Meistens reicht ihr PackageInfo aus, wie im Abschnitt „Daraus ein richtiges .hpkg-Paket machen“ beschrieben.
Ich muss etwas tun ist
Sie können verwenden hpkg-creator (Bei mir stürzt es ab, Fehler melden)

Es ist nicht klar, was zu tun ist. Ich schätze, ich brauche einen Anfängerleitfaden im Hello-World-Stil, idealerweise ein Video. Es wäre schön, auch eine praktische Einführung in HaikuPorter zu haben, wie es in GNU Hallo der Fall ist.

Ich lese folgendes:

haikuporter ist ein Tool zum Erstellen allgemeiner Paketprojekte für Haiku. Es nutzt das HaikuPorts-Repository als Basis für alle Pakete. Zur Erstellung von Paketen werden Haikuporter-Rezepte verwendet.

Außerdem erfahre ich, dass:

Es ist nicht erforderlich, Rezepte im HaikuPorts-Speicher zu speichern. Sie können ein weiteres Repository erstellen, die Rezepte darin ablegen und dann haikuporter darauf verweisen.

Genau das, was ich brauche – wenn ich nicht nach einer Möglichkeit suche, das Paket öffentlich zu veröffentlichen. Aber das ist ein Thema für einen anderen Beitrag.

Haikuporter und Haikuports installieren

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/ # make it runnable from anywhere
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

Ein Rezept schreiben

SUMMARY="Demo QtQuick application"
DESCRIPTION="QtQuickApp is a demo QtQuick application for testing Haiku porting and packaging"
HOMEPAGE="https://github.com/probonopd/QtQuickApp"
COPYRIGHT="None"
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
}

Zusammenstellen des Rezepts

Ich speichere die Datei unter dem Namen QtQuickApp-1.0.recipe, danach starte ich aikuporter -S ./QuickApp-1.0.recipe. Abhängigkeiten werden für alle Pakete im Repository überprüft Haikuports, was einige Zeit in Anspruch nimmt. Ich gehe mir einen Kaffee holen.

Warum um alles in der Welt sollte diese Überprüfung auf meinem lokalen Computer durchgeführt werden und nicht einmal für alle einmal zentral auf dem Server?

Laut Herrn. waddlesplash:

Damit können Sie jede Datei im Repository neu schreiben. 😉 Sie können dies ein wenig optimieren, indem Sie bei Bedarf die erforderlichen Informationen berechnen, da die letzten vorgenommenen Änderungen recht selten sind.

~/QtQuickApp> haikuporter  QtQuickApp-1.0.recipe
Checking if any dependency-infos need to be updated ...
Looking for stale dependency-infos ...
Error: QtQuickApp not found in repository

Es stellt sich heraus, dass es keine reguläre Rezeptdatei gibt, die den Quellcode Ihrer Anwendung enthält. Sie müssen es in einem Repository im HaikuPorts-Format aufbewahren.

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

Dieser Umstand macht die Montage umständlicher. Es gefällt mir nicht besonders, aber ich denke, es ist notwendig, damit irgendwann die gesamte Open-Source-Software in HaikuPorts erscheint.

Ich bekomme Folgendes:

~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe
Checking if any dependency-infos need to be updated ...
        updating dependency infos of QtQuickApp-1.0
Looking for stale dependency-infos ...
Error: QtQuickApp-1.0.recipe not found in tree.

Was ist los? Nachdem ich IRC gelesen habe, mache ich:

~/QtQuickApp> haikuporter -S QtQuickApp
Checking if any dependency-infos need to be updated ...
        updating dependency infos of QtQuickApp-1.0
Looking for stale dependency-infos ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Downloading: https://github.com/probonopd/QtQuickApp.git ...
--2019-07-14 16:12:44--  https://github.com/probonopd/QtQuickApp.git
Resolving github.com... 140.82.118.3
Connecting to github.com|140.82.118.3|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://github.com/probonopd/QtQuickApp [following]
--2019-07-14 16:12:45--  https://github.com/probonopd/QtQuickApp
Reusing existing connection to github.com:443.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘/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’ saved [90094]
Validating checksum of QtQuickApp.git
Warning: ----- CHECKSUM TEMPLATE -----
Warning: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"
Warning: -----------------------------
Error: No checksum found in recipe!

Es ist eine interessante Frage aufgetaucht. Wenn ich dem Rezept eine Prüfsumme hinzufüge, stimmt sie dann mit dem neuesten Git-Commit für die kontinuierliche Integration überein? (Der Entwickler bestätigt: „Es wird nicht funktionieren. Die Rezepte sind relativ stabil ausgelegt.“)

Fügen Sie zum Spaß noch Folgendes zum Rezept hinzu:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Immer noch nicht zufrieden:

~/QtQuickApp> haikuporter -S QtQuickApp
Checking if any dependency-infos need to be updated ...
        updating dependency infos of QtQuickApp-1.0
Looking for stale dependency-infos ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------
Skipping download of source for QtQuickApp.git
Validating checksum of QtQuickApp.git
Unpacking source of QtQuickApp.git
Error: Unrecognized archive type in file /boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git

Was macht er? Schließlich handelt es sich um ein Git-Repository, der Code ist bereits direkt vorhanden, es gibt nichts zu entpacken. Aus meiner Sicht sollte das Tool intelligent genug sein, nicht nach einem Entpacker zu suchen, wenn dieser über der GitHub-URL liegt.

Vielleicht funktioniert uri git://

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

Jetzt beschwert es sich so:

Downloading: git://github.com/probonopd/QtQuickApp.git ...
Error: Downloading from unsafe sources is disabled in haikuports.conf!

Hmm, warum ist alles so kompliziert, warum kann man nicht „einfach arbeiten“? Schließlich ist es nicht ungewöhnlich, etwas über GitHub zu erstellen. Egal, ob es sich um Tools handelt, die sofort funktionieren, ohne dass eine Einrichtung erforderlich ist oder wie ich es nenne: „Aufhebens“.

Vielleicht funktioniert es so:

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

Nein. Ich erhalte immer noch diesen seltsamen Fehler und tue Folgendes: wie hier beschrieben

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

Ich gehe etwas weiter, aber warum schreit es mich an (GitHub ist nicht sicher!) und versucht immer noch, etwas zu entpacken?

Согласно Herr. watschelnsplash:

Nun ja, der Grund war der Wunsch, die Integrität der zur Zusammenstellung empfangenen Daten zu überprüfen. Eine der Möglichkeiten besteht darin, die Prüfsumme des Archivs zu überprüfen, aber Sie können natürlich auch einzelne Dateien hashen, was nicht implementiert wird, weil es dauert viel länger. Die Folge davon ist die „Unsicherheit“ von Git und anderen VCS. Dies wird höchstwahrscheinlich immer der Fall sein, da das Erstellen eines Archivs auf GitHub recht einfach und oft schneller ist. Na ja, in Zukunft wird die Fehlermeldung vielleicht nicht mehr so auffällig sein... (wir führen solche Rezepte nicht mehr in HaikuPorts zusammen).

~/QtQuickApp> haikuporter -S QtQuickApp
Checking if any dependency-infos need to be updated ...
Looking for stale dependency-infos ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Downloading: git+https://github.com/probonopd/QtQuickApp.git ...
Warning: UNSAFE SOURCES ARE BAD AND SHOULD NOT BE USED IN PRODUCTION
Warning: PLEASE MOVE TO A STATIC ARCHIVE DOWNLOAD WITH CHECKSUM ASAP!
Cloning into bare repository '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
Unpacking source of QtQuickApp.git
tar: /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
Command 'git archive HEAD | tar -x -C "/boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0"' returned non-zero exit status 2

Aus alter Gewohnheit frage ich gute Leute auf dem #haiku-Kanal im Netzwerk irc.freenode.net. Und wo wäre ich ohne sie? Nach dem Hinweis wurde mir klar, dass ich Folgendes verwenden sollte:

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

Okay, es wurde klar, was es tut – es lädt ein Archiv mit dem Quellcode einer bestimmten Revision herunter. Aus meiner Sicht ist das dumm und nicht genau das, was ich wollte, nämlich die neueste Revision aus dem Master-Zweig herunterzuladen.

Einer der Entwickler hat es so erklärt:

Wir haben unser eigenes CI, sodass alles, was im Haikuports-Repository abgelegt wird, für alle Benutzer gepackt wird, und wir möchten nicht das Risiko eingehen, „alles in der neuesten Version im Upstream“ zu sammeln und bereitzustellen.

Verstanden! Auf jeden Fall ist Folgendes passiert:

waiting for build package QtQuickApp-1.0-1 to be activated
waiting for build package QtQuickApp-1.0-1 to be activated
waiting for build package QtQuickApp-1.0-1 to be activated
waiting for build package QtQuickApp-1.0-1 to be activated
waiting for build package QtQuickApp-1.0-1 to be activated
(...)

Es wiederholt dies bis ins Unendliche. Anscheinend handelt es sich hierbei um einen Fehler (gibt es eine Anwendung? Ich konnte sie nicht finden).

С haikuporter und Repository Haikuports Es hat nicht den Eindruck, dass es „einfach funktioniert“, aber als Entwickler gibt es einige Dinge, die mir an der Arbeit mit Haiku gefallen. Im Großen und Ganzen ähnelt es dem Open Build Service, einer Reihe von Tools zum Erstellen von Linux-Builds: extrem leistungsstark, mit einem systematischen Ansatz, aber für meine kleine „Hallo Welt“-Anwendung zu viel des Guten.

Nochmals, laut Herrn. waddlesplash:

Tatsächlich ist HaikuPorter standardmäßig ziemlich streng (außerdem gibt es einen Lint-Modus sowie einen Strict-Modus, um es noch strenger zu machen!), aber nur, weil es Pakete erstellt, die funktionieren, und nicht nur Pakete. Deshalb beschwert er sich über nicht deklarierte Abhängigkeiten, nicht ordnungsgemäß importierte Bibliotheken, falsche Versionen usw. Das Ziel besteht darin, alle Probleme, auch zukünftige, zu erkennen, bevor der Benutzer davon erfährt (aus diesem Grund war die Installation von avrdude nicht möglich, da die Abhängigkeit tatsächlich im Rezept angegeben war). Bibliotheken sind nicht nur einzelne Pakete oder gar bestimmte SO-Versionen. HaikuPorter stellt sicher, dass all dies in den Rezepten selbst beachtet wird, um Fehler bei der Ausführung zu vermeiden.

Prinzipiell ist dieser Grad an Genauigkeit bei der Erstellung eines Betriebssystems gerechtfertigt, für eine „Hallo Welt“-Anwendung erscheint er mir jedoch unnötig. Ich beschloss, etwas anderes auszuprobieren.

Erstellen Sie Anwendungen im HPKG-Format mit dem Befehl „package create“.

Kann sein, diese Funktionieren einfache Anweisungen für mich besser?

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

summary "Demo QtQuick application"
description "QtQuickApp is a demo QtQuick application for testing Haiku porting and packaging"

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# See below if you also want the application
# to appear in the menu

Unerwartet schnell, unerwartet einfach, unerwartet effektiv. Genau so, wie ich es mag, großartig!

Installation – was und wo?

Die Datei QtQuickApp.hpkg wurde nach verschoben ~/config/packagesmit einem Dateimanager, woraufhin QtQuickApp auf magische Weise erschien ~/config/apps.
Auch hier unerwartet schnell, einfach und effektiv. Erstaunlich, unglaublich!

Aber... (wo wären wir ohne sie!)

Die App fehlt immer noch in der Apps-Menüliste und im QuickLaunch. Ich glaube, ich weiß bereits, wie ich das Problem beheben kann. Im Dateimanager verschiebe ich QtQuickApp.hpkg von ~/config/packages nach /system/packages.

Nein, fehlt immer noch. Anscheinend habe ich (naja, und die Anleitung) etwas übersehen.

Nachdem ich mir die Registerkarte „Inhalte“ in HaikuDepot für einige andere Anwendungen angesehen habe, habe ich festgestellt, dass es Dateien wie gibt /data/mimedb/application/x-vnd... Was noch bemerkenswerter ist, ist /data/deskbar/menu/Applications/….

Nun, was soll ich da hinstellen? Aufleuchten...

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 die Fragen bleiben: Warum ist das notwendig, wofür? Ich denke, das zerstört den Gesamteindruck, dass das System so ausgefeilt ist.

Wie von Herrn erklärt waddlesplash:

Manchmal gibt es Anwendungen, die andere Anwendungen benötigen, sich aber nicht im Menü befinden. Zum Beispiel LegacyPackageInstaller in Ihrem Screenshot, der .pkg-Archive im BeOS-Format verarbeitet. Ich möchte, dass Benutzer sie installieren, aber ihre Anwesenheit im Menü wird zu Verwirrung führen.

Aus irgendeinem Grund scheint es mir zum Beispiel eine einfachere Lösung zu geben Hidden=true in Dateien .desktop unter Linux. Warum nicht die „versteckten“ Informationen zu einer Ressource und einem Attribut des Dateisystems machen?

Was besonders unauffällig ist, ist der Name (einer) Anwendung, die das Menü anzeigt. deskbar, unterwegs fest gefesselt.

Herr. waddlesplash erklärt dies:

„Deskbar“ ist in diesem Fall als eine Art Oberbegriff zu verstehen (ähnlich wie „Taskbar“, der sich sowohl auf die Windows-Anwendung als auch auf das Gesamtkonzept bezieht). Nun ja, seitdem deskbar, nicht „Deskbar“, dies kann auch ähnlich verstanden werden.

2 „fast identische“ Verzeichnisse mit Anwendungen darin

Warum gibt es zwei Verzeichnisse mit Anwendungen und warum befindet sich meine QtQuickApplication in einem, aber nicht im anderen? (Immerhin handelt es sich hierbei nicht um ein System-, sondern um ein Zweitbenutzer-System, was für mich persönlich verständlich wäre).
Ich bin wirklich verwirrt und denke, dass dies vereinheitlicht werden sollte.

Kommentar von Herrn watschelnsplash

Der Apps-Katalog enthält Anwendungen, die im Menü nicht benötigt werden. Aber die Situation mit dem Menü muss wirklich verbessert werden, um es anpassbarer zu machen.

Bewerbung, sonst passiert es nicht 😉

Ich habe mich gefragt: Ist es wirklich notwendig, Anwendungen zu hosten? /system/apps, wenn Benutzer sie dort sehen, ist das unerwünscht. Vielleicht wäre es besser, sie an einem anderen Ort zu platzieren, wo der Benutzer ihnen nicht begegnet? Genau wie es in Mac OS X gemacht wird, wo der Inhalt von Paketen .app, die für den Benutzer nicht sichtbar sein sollte /Applications, versteckt in den Tiefen von /System/Library/…“`.

Was ist mit Abhängigkeiten?

Ich denke, es lohnt sich, die Abhängigkeiten irgendwie anzugeben, oder? Kann Qt standardmäßig als obligatorischer Bestandteil der Haiku-Installation betrachtet werden? Nein! Qt ist standardmäßig nicht installiert. Kann ein Paketersteller Abhängigkeiten automatisch erkennen, indem er ELF-Dateien überprüft? Mir wurde gesagt, dass HaikuPorter dies tatsächlich tut, aber package Nein. Das liegt daran, dass es sich lediglich um einen „Paketersteller“ handelt, der lediglich selbst Dateien erstellt hpkg.

Sollte Haiku ausgefeilter gemacht werden, indem eine Richtlinie hinzugefügt wird, die besagt, dass ein Paket keine Abhängigkeiten von Paketen außerhalb von Haiku haben sollte? haikuports? (Das würde ich gerne, denn eine solche Richtlinie würde die Sache viel einfacher machen – das System wäre in der Lage, die Abhängigkeiten jedes von irgendwoher heruntergeladenen Pakets automatisch aufzulösen, ohne mit zusätzlichen Paketquellen herumzuspielen.)

Herr. waddlesplash erklärt:

Wir möchten die Freiheit der Entwickler nicht so sehr einschränken, denn es ist offensichtlich, dass CompanyX, wenn es seine eigene Software mit Abhängigkeiten (und damit ein Repository) unterstützen möchte, dies völlig frei tun wird.

In diesem Fall könnte es sich lohnen, Paketen von Drittanbietern zu empfehlen, Abhängigkeiten von Dingen zu vermeiden, die nicht in Haikuports enthalten sind, indem sie alles, was benötigt wird, vollständig in die Anwendung packen. Aber ich denke, das ist ein Thema für einen zukünftigen Artikel dieser Serie. [Geht der Autor in Richtung AppImage? — ca. Übersetzer]

Hinzufügen eines Anwendungssymbols

Was passiert, wenn ich eines der netten integrierten Symbole zu den Ressourcen meiner neu erstellten Anwendung hinzufügen möchte? Es stellt sich heraus, dass dies ein erstaunliches Thema ist und daher die Grundlage für den nächsten Artikel bilden wird.

Wie organisiert man kontinuierliche Anwendungsbuilds?

Stellen Sie sich ein Projekt wie Inkscape vor (ja, ich weiß, dass es in Haiku noch nicht verfügbar ist, aber es lässt sich bequem darauf anzeigen). Sie verfügen über ein Quellcode-Repository https://gitlab.com/inkscape/inkscape.
Jedes Mal, wenn jemand seine Änderungen in das Repository überträgt, werden Build-Pipelines gestartet. Anschließend werden die Änderungen automatisch getestet, erstellt und die Anwendung in verschiedene Pakete gepackt, einschließlich AppImage für Linux (ein eigenständiges Anwendungspaket, das unabhängig davon zum lokalen Testen heruntergeladen werden kann). was auf dem System installiert sein darf und was nicht [Ich wusste es! — ca. Übersetzer]). Das Gleiche passiert bei jeder Zweigzusammenführungsanforderung. Sie können also vor der Zusammenführung die Anwendung herunterladen, die aus dem in der Zusammenführungsanforderung vorgeschlagenen Code erstellt wurde.

Zusammenführungsanfragen mit Build-Status und der Möglichkeit, die kompilierten Binärdateien herunterzuladen, wenn der Build erfolgreich ist (grün markiert)

Der Build läuft in Docker-Containern. GitLab bietet kostenlose Läufer für Linux an, und ich denke, dass es möglich sein könnte, eigene Läufer einzubinden (übrigens sehe ich nicht, wie das für Systeme wie Haiku funktionieren würde, von denen ich weiß, dass sie kein Docker oder ein gleichwertiges System haben, aber Auch für FreeBSD gibt es kein Docker, sodass dieses Problem nicht nur bei Haiku auftritt.

Idealerweise können Haiku-Anwendungen in einem Docker-Container für Linux erstellt werden. In dieser Situation kann die Baugruppe für Haiku in bestehende Rohrleitungen eingeführt werden. Gibt es Cross-Compiler? Oder sollte ich das gesamte Haiku in einem Docker-Container mit etwas wie QEMU/KVM emulieren (vorausgesetzt, dass es in Docker so funktioniert)? Übrigens nutzen viele Projekte ähnliche Prinzipien. Scribus macht das zum Beispiel – es ist bereits für Haiku verfügbar. Eines Tages wird der Tag kommen, an dem ich senden kann so Ziehen Sie Anfragen an andere Projekte, um Haiku-Unterstützung hinzuzufügen.

Einer der Entwickler erklärt:

Für andere Projekte, die selbst Pakete erstellen möchten, wird die reguläre CMake/CPack-Methode unterstützt. Andere Build-Systeme können durch den direkten Aufruf des Build-Programms des Pakets unterstützt werden, was in Ordnung ist, wenn Leute daran interessiert sind. Die Erfahrung zeigt: Bisher gab es kein großes Interesse, daher funktionierte Haikuporter für uns als praktisch, aber letztendlich sollten beide Methoden zusammenarbeiten. Wir sollten eine Reihe von Tools für die Cross-Building-Software von Linux oder einem anderen Server-Betriebssystem einführen (Haiku ist nicht für die Ausführung auf Servern konzipiert).

Ich gebe stehende Ovationen. Normale Linux-Benutzer tragen all diese zusätzliche Last und zusätzlichen Ballast (Sicherheit, strenge Kontrolle usw.), die für ein Server-Betriebssystem erforderlich sind, nicht jedoch für ein persönliches. Daher stimme ich voll und ganz zu, dass die Möglichkeit, Haiku-Apps unter Linux zu erstellen, der richtige Weg ist.

Abschluss

Die Portierung von POSIX-Anwendungen nach Haiku ist möglich, kann aber teurer sein als ein typischer Neuaufbau. Ohne die Hilfe der Leute vom #haiku-Kanal im Netzwerk irc.freenode.net würde ich auf jeden Fall noch lange damit beschäftigt sein. Aber selbst sie erkannten nicht immer sofort, was los war.

Eine einfache Ausnahme bilden in Qt geschriebene Anwendungen. Ich habe ohne Probleme eine einfache Demoanwendung zusammengestellt.

Das Erstellen eines Pakets für einfache Anwendungen ist ebenfalls recht einfach, allerdings nur für „traditionell veröffentlichte“, d. h. Versionierte Quellcode-Archive zur Unterstützung in Haikuports haben. Für einen kontinuierlichen Build (Build für jedes Commit von Änderungen) mit GitHub scheint nicht alles so einfach zu sein. Hier fühlt sich Haiku eher wie eine Linux-Distribution an als wie das Ergebnis auf einem Mac, wo man ein Paket erhält, wenn man in XCode auf die Schaltfläche „Build“ klickt .app, bereit zum Einfügen in ein Disk-Image .dmg, zum Download auf meiner Website vorbereitet.
Die kontinuierliche Erstellung von Anwendungen auf Basis eines „Server“-Betriebssystems, beispielsweise Linux, wird höchstwahrscheinlich möglich sein, wenn die Nachfrage von Entwicklern besteht, aber im Moment hat das Haiku-Projekt andere, dringendere Aufgaben.

Versuch es selber! Immerhin stellt das Haiku-Projekt Images zum Booten von DVD oder USB bereit täglich. Zur Installation laden Sie einfach das Image herunter und schreiben es mit auf ein Flash-Laufwerk Radierer

Haben Sie irgendwelche Fragen? Wir laden Sie zum Russischsprechen ein Telegrammkanal.

Fehlerübersicht: Wie man sich in C und C++ selbst ins Bein schießt. Haiku OS-Rezeptsammlung

Von Autor Übersetzung: Dies ist der fünfte Artikel in der Serie über Haiku.

Liste der Artikel: erste Die zweite Dritte Viertens

Source: habr.com

Mein fünfter Tag mit Haiku: Lasst uns einige Programme portieren