Mäi fënneften Dag mam Haiku: loosst eis e puer Programmer portéieren

TL; DR: En Newbie huet Haiku fir d'éischte Kéier gesinn, probéiert e puer Programmer aus der Linux Welt ze portéieren.

Meng éischt Haiku portéiert Programm, verpackt a sengem hpkg Format

Viru kuerzem Ech hunn Haiku entdeckt, en iwwerraschend gutt Betribssystem fir PCs.
Haut wäert ech léieren wéi nei Programmer op dëse Betribssystem port. Den Haaptfokus ass eng Beschreiwung vun der éischter Erfahrung vum Wiessel op Haiku aus der Siicht vun engem Linux Entwéckler. Ech entschëllege mech fir all domm Feeler, déi ech ënnerwee gemaach hunn, well et ass nach net emol eng Woch zënter ech fir d'éischt den Haiku erofgelueden hunn.

Ech wëll dräi Ziler erreechen:

• Port eng einfach CLI Applikatioun
• Port eng Applikatioun aus GUI zu Qt
• Da packt se an hpkg Format (well ech nach drun denken AppDir an AppImage fir Haiku unzepassen ...)

Loosst eis ufänken. An Sektiounen Dokumentatioun и Entwécklungwéi och an Wiki vun HaikuPorts hunn ech déi richteg Richtung fonnt. Et gëtt souguer en online PDF Buch BeOS: Porting eng Unix Applikatioun.
467 Säiten - an dëst ass vun 1997! Et ass grujeleg fir dobannen ze kucken, awer ech hoffen op dat Bescht. D'Wierder vum Entwéckler sinn encouragéierend: "et huet laang gedauert well BeOS net POSIX-kompatibel war", awer Haiku "fir de gréissten Deel" ass scho sou.

Porting eng einfach CLI Applikatioun

Den éischte Gedanken war d'Applikatioun ze portéieren avrdude, mee wéi et sech erausstellt, ass dat schonn gemaach viru laanger Zäit.

Éischt Versuch: näischt ze kucken

Wat ech net verstinn ass dat schonn Apps sinn fir iwwer 10 Joer op Haiku portéiert ginn - trotz der Tatsaach datt d'OS selwer nach net emol Versioun 1.0 ass.

Zweete Versuch: muss nei schreiwen

Also wäert ech benotzen ptouch-770, CLI fir de Brother P-Touch 770 Drécker ze kontrolléieren deen ech benotze fir Etiketten ze drécken.
Ech Drécken verschidden Etiketten op et, an Dir hutt vläicht schonn am virdrun Artikel gesinn. E bësse méi fréi hunn ech e klenge GUI Wrapper Programm am Python geschriwwen (well et am Gtk + ass, muss et nei geschriwwe ginn, an dëst ass e gudde Grond fir ze léieren).

Brudder P-Touch 770 Label Dréckerspäicher Wierker et mat Haiku?

Den Haiku Package Manager weess iwwer Bibliothéiken a Kommandoen, also wann ech e "kann net fannen libintl" Message kréien wann ech lafen configure - Ech lancéiere just pkgman install devel:libintl an déi néideg Pak wäert fonnt ginn. Ähnlech pkgman install cmd:rsync. Well, etc.

Ausser wann dëst net funktionnéiert:

/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

Vläicht ass udev ze Linux-baséiert an existéiert dofir net fir Haiku. Wat heescht datt ech de Quellcode muss änneren, deen ech versichen ze kompiléieren.
Ee, Dir kënnt net iwwer de Kapp sprangen, an ech weess net mol wou ufänken.

Drëtte Versuch

Et wier flott ze hunn tmate fir Haiku, da géif ech den Haiku Entwéckler erlaben op meng Terminal Sessioun ze verbannen - am Fall wou eppes falsch geet. D'Instruktioune si ganz einfach:

./autogen.sh
./configure
make
make install

Gesäit gutt aus, also firwat probéiert et net op 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 dësem Schrëtt oppen ech HaikuDepot a sichen curses.
Eppes gouf fonnt, wat mir en Hiweis fir eng méi kompetent Ufro ginn huet:

/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

Erëm gaangen ech HaikuDepot, an, natierlech, fonnt devel:msgpack_c_cpp_devel. Wat sinn dës komesch Nimm?

/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

Op dësem Schrëtt hunn ech gemierkt datt de Porting vun engem Programm op Haiku vill méi Wëssen erfuerdert wéi néideg ass fir en einfachen Opbau.
Ech hunn mat de frëndlechen Haiku Entwéckler geschwat, et stellt sech eraus datt et e Feeler am msgpack ass, an no e puer Minutten gesinn ech e Patch an HaikuPorts. Ech kann mat mengem eegenen Aen gesinn wéi de korrigéierte Pak hei goen (Buildslave - virtuell Maschinnen).

Baut de korrigéierte Msgpack op buildmaster

Zwëschen Zäiten schécken ech e Patch op Upstream fir Haiku Support op msgpack ze addéieren.

Fënnef Minutte méi spéit ass den aktualiséierten msgpack schonn an 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.

Onerwaart gutt. Hunn ech dat gesot?!

Ech kommen zréck op den urspréngleche 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

Elo gesäit et aus wéi wann msgpack net schëlleg ass. Ech kommentéieren IMAXLABEL в tty.c sou:

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

Resultat:

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.

Majo, da geet et erëm... Iwwregens:

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

Mr. waddlesplash seet Iech wou ze graven:

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

Hei hunn ech gepost config.log.

Si hunn mir erkläert datt et soss eppes am libnetwork zousätzlech zu libresolv op Haiku ass. Anscheinend muss de Code weider geännert ginn. Muss denken ...

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

Déi éiweg Fro: Wat ass lass?

/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

Déi selwecht Saach, nëmmen am Profil. Googlet an dëst fonnt. Wann Dir derbäi -lssp "heiansdo" hëlleft, ech probéieren:

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

Wow! Et fänkt un! Awer…

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

Ech probéieren ze Debuggen Fichier hei:

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

"Bad Port ID" ass scho wéi eng Visittekaart haiku. Vläicht huet iergendeen eng Iddi wat falsch ass a wéi et ze fixéieren? Wann jo, aktualiséieren ech den Artikel. Link zu GitHub.

Porting der GUI Applikatioun ze Qt.

Ech wielen eng einfach QML Applikatioun.

/> 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!

Wierklech einfach. Manner wéi eng Minutt!

Verpackungsapplikatiounen an hpkg mat Haikuporter an Haikuports.

Mat wat soll ech ufänken? Et gëtt keng einfach Dokumentatioun, ech ginn op den #haiku Kanal op irc.freenode.net an héieren:

• Equipe package - e Low-Level Wee fir Packagen ze kreéieren. Fir de gréissten Deel ass PackageInfo genuch fir hatt, wéi beschriwwen an der Rubrik "Et an e richtegt .hpkg Package maachen"
• Ech muss eppes maachen sou e
• Kann se benotzen hpkg-creator (et klappt fir mech, Feeler Berichterstattung)

Et ass net kloer wat ze maachen. Ech mengen ech brauch en Hello World Style Ufänger Guide, am Idealfall e Video. Et wier flott och eng praktesch Aféierung an HaikuPorter ze hunn, wéi am GNU Hallo gemaach.

Ech liesen déi folgend:

haikuporter ass en Tool fir gemeinsame Packageprojete fir Haiku ze kreéieren. Et benotzt den HaikuPorts Repository als Basis fir all Packagen. Haikuporter Rezepter gi benotzt fir Packagen ze kreéieren.

Zousätzlech fannen ech eraus datt:

Et gëtt kee Besoin fir Rezepter an der HaikuPorts Lagerung ze späicheren. Dir kënnt en anere Repository maachen, d'Rezepter dran setzen, an dann Haikuporter drop weisen.

Just wat ech brauch - wann net no engem Wee sichen fir de Package ëffentlech ze verëffentlechen. Awer dëst ass en Thema fir en anere Post.

Installatioun haikuporter an 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/ # 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

Schreift e Rezept

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
}

D'Rezept montéieren

Ech späicheren de Fichier ënnert dem Numm QtQuickApp-1.0.recipe, no deem ech starten aikuporter -S ./QuickApp-1.0.recipe. Ofhängegkeete gi fir all Packagen am Repository iwwerpréift haikuports, wat e bëssen Zäit brauch. Ech ginn Kaffi drénken.

Firwat op der Äerd soll dës kontrolléieren op meng lokal Maschinn gemaach ginn, an net zentral op de Server eemol fir jiddereen?

Laut dem Mr. waddlesplash:

Mat esou datt Dir all Datei am Repository iwwerschreiwe kënnt 😉 Dir kënnt dëst e bëssen optimiséieren, déi néideg Informatioune berechent wann néideg, well déi lescht Ännerungen déi gemaach gi sinn zimlech seelen.

~/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

Et stellt sech eraus datt et net sou eppes ass wéi eng regulär Rezeptdatei déi de Quellcode vun Ärer Applikatioun enthält. Dir musst et an engem Repository am HaikuPorts Format halen.

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

Dës Tatsaach mécht d'Versammlung méi ëmständlech. Ech hunn et net besonnesch gär, awer ech mengen et ass néideg fir datt schliisslech all Open Source Software an HaikuPorts erschéngt.

Ech kréien déi folgend:

~/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.

Wat ass falsch? Nodeems ech irc gelies hunn, maachen ech:

~/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!

Eng interessant Fro ass opgestan. Wann ech e Checksum zum Rezept addéieren - passt et mat der leschter Git-Verpflichtung fir kontinuéierlech Integratioun? (Den Entwéckler bestätegt: "Et wäert net schaffen. D'Rezepter sinn entwéckelt fir relativ stabil ze sinn.")

Fir Spaass, füügt d'Rezept un:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Nach ëmmer net zefridden:

~/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

Wat mecht hien? No allem ass dëst e Git Repository, de Code ass schonn direkt do, et gëtt näischt auszepaken. Aus menger Siicht soll den Tool intelligent genuch sinn fir net no engem Unpacker ze sichen wann et iwwer der GitHub URL ass.

Vläicht uri git: // wäert funktionnéieren

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

Elo beschwéiert et esou:

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

Hmm, firwat ass alles sou komplizéiert, firwat kënnt Dir net "just schaffen"? No allem ass et net sou ongewéinlech eppes vu GitHub ze bauen. Egal ob et Tools sinn déi direkt funktionnéieren, ouni de Besoin fir Setup, oder wéi ech et "Fussing" nennen.

Vläicht wäert et esou funktionnéieren:

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

Nee. Ech kréien nach ëmmer dëse komesche Feeler a maachen, wéi hei beschriwwen

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

Ech réckelen e bësse méi wäit, awer firwat jäizt et op mech (GitHub ass net sécher!) a probéiert ëmmer nach eppes auszepaken.

Nëmmen Mr. waddlesplash:

Gutt, jo, de Grond war de Wonsch d'Integritéit vun den Donnéeën ze kontrolléieren fir d'Montage ze kréien. Eng vun den Optiounen ass d'Checksum vum Archiv z'iwwerpréiwen, awer Dir kënnt natierlech eenzel Dateien hashéieren, déi net ëmgesat ginn, well et dauert vill méi laang. D'Konsequenz dovun ass d'"Onsécherheet" vu Git an aner VCS. Dëst wäert héchstwahrscheinlech ëmmer de Fall sinn, well en Archiv op GitHub erstellen ass zimmlech einfach an dacks méi séier. Gutt, an Zukunft wäert d'Fehlermeldung vläicht net sou blénkeg sinn ... (mir fusionéieren net méi esou Rezepter an HaikuPorts).

~/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 aler Gewunnecht froen ech gutt Leit um #haiku Kanal um irc.freenode.net Netzwierk. A wou wier ech ouni si? Nom Hiweis hunn ech gemierkt datt ech sollt benotzen:

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

Okay, et gouf kloer wat et mécht - et luet en Archiv mat dem Quellcode vun enger bestëmmter Versioun erof. Et ass domm, aus menger Siicht, an net genee wat ech wollt, nämlech déi lescht Versioun vum Master Branche erofzelueden.

Ee vun den Entwéckler huet et esou erkläert:

Mir hunn eisen eegene CI, sou datt alles wat am Haikuports Repository plazéiert ass fir all Benotzer verpackt ginn, a mir wëllen net riskéieren "alles an der leschter Versioun Upstream" ze sammelen an ze liwweren.

Verstoen! Op alle Fall ass dat geschitt:

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
(...)

Et widderhëlt dëst ad infinitum. Anscheinend ass dëst e Feeler (gëtt et eng Applikatioun? Ech konnt se net fannen).

С haikuporter an Repository haikuports Et huet net e "just funktionnéiert" Gefill, awer als Entwéckler sinn et e puer Saachen déi ech gär hunn iwwer d'Aarbecht mat Haiku. Fir de gréissten Deel ass et ähnlech wéi den Open Build Service, eng Rei vun Tools fir Linux Builds ze bauen: extrem mächteg, mat enger systematesch Approche, awer iwwerkill fir meng kleng "Hallo Welt" Applikatioun.

Nach eng Kéier, laut dem Mr. waddlesplash:

Tatsächlech ass HaikuPorter zimmlech strikt par défaut (plus et gëtt e Lint Modus souwéi e strenge Modus fir et nach méi strikt ze maachen!), Awer nëmme well et Packagen erstellt déi funktionnéieren, anstatt just Packagen ze kreéieren. Dofir beschwéiert hien sech iwwer net deklaréiert Ofhängegkeeten, net richteg importéiert Bibliothéiken, falsch Versiounen, asw. D'Zil ass all Problemer ze fänken, och zukünfteg, ier de Benotzer doriwwer weess (dofir war et net méiglech avrdude z'installéieren, well d'Ofhängegkeet tatsächlech am Rezept spezifizéiert gouf). Bibliothéike sinn net nëmmen individuell Packagen oder souguer spezifesch SO Versiounen. HaikuPorter garantéiert datt all dëst an de Rezepter selwer beobachtet gëtt fir Feeler während der Ausféierung ze vermeiden.

Am Prinzip ass dësen Niveau vun Rigoritéit gerechtfäerdegt wann Dir e Betribssystem erstellt, awer et schéngt mir onnéideg fir eng "Hallo Welt" Applikatioun. Ech hu beschloss eppes anescht ze probéieren.

Bauen Uwendungen am hpkg Format mam Kommando "Package erstellen".

Vläicht, dat Sinn einfach Instruktioune besser fir mech?

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

Onerwaart séier, onerwaart einfach, onerwaart effektiv. Genau wéi ech et gär hunn, erstaunlech!

Installatioun - wat a wou?

Geplënnert der QtQuickApp.hpkg Fichier ze ~/config/packagesengem Fichier Manager benotzt, no deem QtQuickApp magesch wossten an ~/config/apps.
Erëm, onerwaart séier, einfach an effektiv. Erstaunlech, onheemlech!

Awer ... (wou wiere mir ouni si!)

D'App fehlt nach ëmmer aus der Apps Menü Lëscht a QuickLaunch. Ech mengen ech weess schon wéi ech et fixéieren. Am Dateimanager plënneren ech QtQuickApp.hpkg aus ~/config/packages op /system/packages.

Nee, vermësst nach. Anscheinend hunn ech (gutt, an d'Instruktioune) eppes verpasst.

Nodeems ech den Tab "Inhalter" am HaikuDepot fir e puer aner Uwendungen gekuckt hunn, hunn ech gesinn datt et Dateien wéi /data/mimedb/application/x-vnd... wat nach méi bemierkenswäert ass /data/deskbar/menu/Applications/….

Ma, wat soll ech do setzen? Komm...

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

Ech si ganz sécher datt dësen Trick funktionnéiert, awer d'Froen bleiwen: firwat ass dat néideg, fir wat ass et? Ech mengen dat ruinéiert den allgemengen Androck datt de System sou sophistikéiert ass.

Wéi erkläert vum Mr. waddlesplash:

Heiansdo ginn et Uwendungen déi aner Uwendungen brauchen awer net am Menü sinn. Zum Beispill LegacyPackageInstaller an Ärem Screenshot, Veraarbechtung .pkg Archiver am BeOS Format. Ech hätt gär datt d'Benotzer se installéieren, awer hir Präsenz am Menü féiert zu Duercherneen.

Aus iergendengem Grond schéngt et mir z.B. eng méi einfach Léisung ze ginn Hidden=true an Dateien .desktop op Linux. Firwat net déi "verstoppt" Informatioun eng Ressource an Attribut vum Dateiesystem maachen?

Wat besonnesch net subtil ass ass den Numm vun (e puer) Applikatioun déi de Menü weist, deskbar, steif laanscht de Wee gebonnen.

Mr. waddlesplash erkläert dëst:

"Deskbar" an dësem Fall soll als eng Aart allgemeng Begrëff verstane ginn (op déiselwecht Manéier wéi "Taskbar", wat souwuel op d'Windows Applikatioun wéi och op d'allgemeng Konzept bezitt). Gutt, zënter dëser deskbar, net "Deskbar", dëst kann och op eng ähnlech Manéier verstane ginn.

2 "bal identesch" Verzeechnes mat Uwendungen an hinnen

Firwat ginn et 2 Verzeechnes mat Uwendungen, an och firwat ass meng QtQuickApplication an engem, awer net an der anerer? (Schliesslech ass dat net een System, mee en zweete Benotzer, wat fir mech perséinlech verständlech wier).
Ech si wierklech duercherneen an ech mengen dat soll vereenegt ginn.

Kommentar vum Mr. waddlesplash

Den Apps Katalog enthält Uwendungen déi net am Menü gebraucht ginn. Awer d'Situatioun mam Menü muss wierklech verbessert ginn, fir et méi personaliséierbar ze maachen.

Applikatioun, oder et geschitt net 😉

Ech hu gefrot: ass et wierklech néideg fir Uwendungen ze hosten /system/apps, Wann d'Benotzer se do gesinn, ass et net wënschenswäert. Vläicht wier et besser, se op eng aner Plaz ze placéieren, wou de Benotzer se net begéint? Just wéi et am Mac OS X gemaach gëtt, wou den Inhalt vu Packagen .app, déi fir de Benotzer net siichtbar sinn soll an /Applications, verstoppt an den Tiefen vun /System/Library/…“`.

Wat iwwer Ofhängegkeeten?

Ech mengen et ass derwäert d'Ofhängegkeeten iergendwéi ze spezifizéieren, richteg? Kann Qt als obligatoresch Deel vun der Haiku Installatioun Par défaut considéréiert ginn? Nee! Qt ass net Par défaut installéiert. Kann e Package Builder automatesch Ofhängegkeeten erkennen andeems Dir ELF Dateien iwwerpréift? Ech war gesot, datt HaikuPorter eigentlech dëst, mä package Nee. Dat ass well et just e "Package Builder" ass dee just Dateien eleng erstellt hpkg.

Sollt Haiku méi raffinéiert gemaach ginn andeems Dir eng Politik bäidréit datt e Package keng Ofhängegkeete vu Packagen ausserhalb vum Haiku sollt hunn? haikuports? (Ech hätt gär, well sou eng Politik d'Saache vill méi einfach mécht - de System wier fäeg d'Ofhängegkeete vun all Package, deen iwwerall erofgeluede gëtt, automatesch ze léisen, ouni mat zousätzleche Packagequellen ëmzegoen.)

Mr. waddlesplash erkläert:

Mir wëllen d'Fräiheet vun den Entwéckler net sou vill limitéieren, well et evident ass datt wann CompanyX säin eegene Set vu Software mat Ofhängegkeeten (an dofir e Repository) wëll ënnerstëtzen, et wäert dat komplett fräi maachen.

An dësem Fall ass et derwäert ze recommandéieren datt Drëtt-Partei-Packagen Ofhängegkeete vermeiden op alles wat net an Haikuports abegraff ass, andeems se alles mat der Applikatioun komplett packen. Awer ech mengen dat ass en Thema fir en zukünfteg Artikel an dëser Serie. [Gitt den Auteur op AppImage? — ca. Iwwersetzer]

Füügt eng Applikatioun Ikon

Wat wann ech eng vun den ordentleche agebaute Symboler op d'Ressourcen vu menger nei erstallt Applikatioun addéiere wëll? Et stellt sech eraus datt dëst en erstaunlech Thema ass, also wäert et d'Basis fir den nächsten Artikel sinn.

Wéi organiséieren kontinuéierlech Applikatiounsbauen?

Stellt Iech e Projet wéi Inkscape vir (jo, ech si bewosst datt et nach net an Haiku verfügbar ass, awer et ass bequem drop ze weisen). Si hunn e Quellcode Repository https://gitlab.com/inkscape/inkscape.
All Kéier wann iergendeen seng Ännerunge fir de Repository engagéiert, gi Pipelines gebaut ginn, duerno ginn d'Ännerungen automatesch getest, gebaut an d'Applikatioun a verschidde Packagen verpackt, dorënner AppImage fir Linux (e Standalone Applikatiounspaket dee ka fir lokal Tester erofgeluede ginn onofhängeg wat kann oder net op de System installéiert ginn [Ech wosst et! — ca. Iwwersetzer]). Datselwecht geschitt mat all Branche Fusiounsufro, sou datt Dir d'Applikatioun eroflueden kënnt aus dem Code proposéiert an der Fusiounsufro virum Fusioun.

Fusioun Ufroe mat Build Statusen an d'Fäegkeet fir déi kompiléiert Binären erofzelueden wann de Build erfollegräich ass (gréng markéiert)

De Bau leeft an Docker Container. GitLab bitt gratis Leefer op Linux, an ech mengen et kéint méiglech sinn Är eege Leefer opzehuelen (iwwregens, ech gesinn net wéi dëst fir Systemer wéi Haiku funktionnéiert, déi ech weess datt se keen Docker oder Äquivalent hunn, awer och fir FreeBSD gëtt et keen Docker, also ass dëse Problem net eenzegaarteg fir Haiku).

Ideal kënnen Haiku Uwendungen an engem Docker Container fir Linux gebaut ginn. An dëser Situatioun kann d'Versammlung fir Haiku an existéierend Pipelines agefouert ginn. Ginn et Cross Compilers? Oder soll ech all Haiku an engem Docker Container emuléieren mat eppes wéi QEMU / KVM (unzehuelen datt et esou am Docker funktionnéiert)? Iwwregens, vill Projeten benotzen ähnlech Prinzipien. Zum Beispill, Scribus mécht dëst - et ass scho fir Haiku verfügbar. Enges Daags wäert kommen wann ech schécken kann esou Pull Ufroe fir aner Projeten fir Haiku Ënnerstëtzung ze addéieren.

Ee vun den Entwéckler erkläert:

Fir aner Projeten déi Packagen selwer wëllen erstellen, gëtt déi regulär CMake / CPack Method ënnerstëtzt. Aner Build Systemer kënnen ënnerstëtzt ginn andeems Dir de Bauprogramm vum Package direkt rufft, wat gutt ass wann d'Leit drun interesséiert sinn. D'Erfahrung weist: bis elo gouf et net vill Interesse, sou datt Haikuporter fir eis bequem geschafft huet, awer schlussendlech solle béid Methoden zesumme schaffen. Mir sollten eng Rei vun Tools fir Cross-Building Software vu Linux oder all anere Serverbetribssystem aféieren (Haiku ass net entwéckelt fir op Serveren ze lafen).

Ech ginn e Standing Ovation. Regelméisseg Linux Benotzer droen all dës zousätzlech Laascht an zousätzlech Gepäck (Sécherheet, strikt Kontroll, etc.) dat fir e Serverbetribssystem noutwendeg ass, awer net fir eng perséinlech. Also ech sinn ganz d'accord datt d'Kapazitéit fir Haiku Apps op Linux ze bauen ass de Wee fir ze goen.

Konklusioun

Porting POSIX Uwendungen op Haiku ass méiglech, awer ka méi deier sinn wéi eng typesch Neiopbau. Ech wier definitiv mat dëser laanger Zäit hänke gelooss, wann et net fir d'Hëllef vu Leit vum #haiku-Kanal um irc.freenode.net Netz wier. Awer och si hunn net ëmmer direkt gesinn wat falsch war.

Uwendungen schrëftlech an Qt sinn eng einfach Ausnam. Ech hunn eng einfach Demo-Applikatioun ouni Probleemer zesummegesat.

E Package fir einfach Uwendungen bauen ass och relativ einfach, awer nëmme fir "traditionell verëffentlecht", d.h. Versioune Quellcodearchiven hunn fir Ënnerstëtzung an Haikuports geduecht. Fir eng kontinuéierlech Build (baut fir all Engagement vun Ännerungen) mat GitHub, schéngt alles net sou einfach ze sinn. Hei fillt Haiku méi wéi eng Linux Verdeelung wéi d'Resultat op engem Mac, wou wann Dir op de "Build" Knäppchen an XCode klickt, kritt Dir e Package .app, prett fir an engem Disk Image agebaut ze ginn .dmg, virbereet fir erofzelueden op menger Websäit.
Kontinuéierlech Gebai vun Uwendungen baséiert op engem "Server" Betribssystem, zum Beispill, Linux, wäert héchstwahrscheinlech méiglech ginn wann et Nofro vun Entwéckler ass, mä de Moment Haiku Projet huet aner, méi dréngend Aufgaben.

Probéiert et selwer! No allem bitt den Haiku-Projet Biller fir op DVD oder USB ze booten, generéiert deeglech. Fir ze installéieren, luet just d'Bild erof a schreift se op e Flash Drive mat Etcher

Hutt Dir Froen? Mir invitéieren Iech op de russesch-allgemengen Telegramm Kanal.

Feeler Iwwersiicht: Wéi schéisst Dir Iech selwer an de Fouss an C an C++. Haiku OS Rezept Sammlung

aus Auteur Iwwersetzung: Dëst ass de fënneften Artikel an der Serie iwwer Haiku.

Lëscht vun den Artikelen: Déi éischt Déi zweet Drëtt Véierten

Source: will.com