TL;DR: De beginner zag Haiku voor het eerst en probeert enkele programma's uit de Linux-wereld te porteren.
Mijn eerste voor Haiku geporteerde programma, verpakt in zijn hpkg-formaat.
Ik ontdekte Haiku, een onverwacht goede besturingssystem voor pc's.
Vandaag ga ik leren hoe ik nieuwe programma's op dit besturingssysteem kan porteren. De belangrijkste focus ligt op het beschrijven van mijn eerste ervaring met de overstap naar Haiku vanuit de ontwikkelaarsperspective voor Linux. Mijn excuses voor de domme fouten die ik in het proces maak, want sinds ik Haiku voor het eerst heb geladen, is er nog geen week verstreken.
Ik wil drie doelen bereiken:
- Een eenvoudige CLI-applicatie porteren.
- Een GUI-applicatie op Qt porteren.
- Deze vervolgens verpakken in het hpkg-formaat (aangezien ik nog steeds nadenk over de aanpassing van AppDir en AppImage voor Haiku…)
Laten we beginnen. In de secties en , evenals in van HaikuPorts heb ik de juiste richting gevonden. Er is zelfs een PDF online boek. .
467 pagina's — en dat sinds 1997! Het is een beetje eng om erin te kijken, maar ik hoop op het beste. De woorden van de ontwikkelaar zijn bemoedigend: "het duurt lang, omdat BeOS niet POSIX-compatibel was", maar Haiku is "voor het grootste deel" dat al.
Porteren van een eenvoudige CLI-toepassing.
Mijn eerste gedachte was om de applicatie , te porteren, maar dat bleek al lang geleden te zijn.
Eerste poging: niets om naar te kijken.
Wat ik echt niet kan begrijpen, is dat er al — terwijl het besturingssysteem nog niet eens versie 1.0 heeft.
Tweede poging: het moet herschreven worden.
Dus ik ga , een CLI voor het beheren van de Brother P-Touch 770-printer, gebruiken om deze labels te printen.
Ik gebruik het om verschillende labels te printen, en je hebt het misschien al gezien in het vorige artikel. Eerder schreef ik een kleine wrapper-applicatie met een GUI in Python (aangezien het op Gtk+ is — dit zal herschreven moeten worden, en dat is een goede aanleiding om iets bij te leren).
Labelsprinter Brother P-Touch 770. Zal het werken onder Haiku?
De Haiku-pakketbeheerder is zich bewust van bibliotheken en commando's, dus als ik de foutmelding "kan libintl niet vinden" krijg bij het opstarten, configure kan ik gewoon pkgman install devel:libintl en het benodigde pakket zal gevonden worden. Op dezelfde manier pkgman install cmd:rsync.. Nou ja, enzovoort.
Behalve in gevallen waarin dit niet werkt:
/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 foundMisschien is udev te linuxachtig, daarom is het er niet voor Haiku. Dit betekent dat ik de broncode moet aanpassen die ik probeer te compileren.
Ah, je kunt niet hoger springen dan je hoofd, en ik weet zelfs niet waar ik moet beginnen.
Derde poging
Het zou fijn zijn om te hebben tmate voor Haiku, dan zou ik de ontwikkelaars van Haiku toelaten om verbinding te maken met mijn terminalsessie - voor het geval er iets misgaat. De instructies zijn vrij eenvoudig:
./autogen.sh
./configure
make
make installZiet er goed uit, dus waarom zou ik het niet proberen 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 foundIn deze stap open ik HaikuDepot en zoek ik naar curses.
Er is iets gevonden dat me een hint gaf voor een beter verzoek:
/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 foundIk ging weer naar HaikuDepot en vond natuurlijk devel:msgpack_c_cpp_devel. Wat zijn dat voor vreemde 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 1In deze stap realiseerde ik me dat het porten van programma's naar Haiku aanzienlijk meer kennis vereist dan nodig is voor een eenvoudige hercompilatie.
Ik sprak met de vriendelijke ontwikkelaars van Haiku, en het bleek dat er een bug is in msgpack, en na een paar minuten zie ik een patch in HaikuPorts. Ik zie met eigen ogen hoe het gecorrigeerde pakket (buildslave - virtuele machines).
De bouw van het gecorrigeerde msgpack op buildmaster
In de tussentijd stuur ik de patch naar upstream .
Vijf minuten later is de bijgewerkte msgpack al beschikbaar in Haiku:
/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.Verassend goed. Heb ik dat gezegd?!
Ik keer terug naar de oorspronkelijke taak:
/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 1Het lijkt er nu op dat msgpack niet de schuldige is. Ik commentarieer IMAXLABEL in tty.c zo:
tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|/*IMAXBEL|*/ISTRIP);Resultaat:
osdep-unknown.c: In functie 'osdep_get_cwd':
osdep-unknown.c:32:19: waarschuwing: ongebruikte parameter 'fd' [-Wunused-parameter]
osdep_get_cwd(int fd)
~~~~^~
make: *** Geen regel om doel 'compat/forkpty-unknown.c' te maken, nodig door 'compat/forkpty-unknown.o'. Stop.Nou daar gaan we weer... Trouwens:
/Haiku/home/tmate> ./configure | grep -i OPENAT
checking for openat... nogeeft aan waar ik moet zoeken:
/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 heb ik geüpload .
Men legde me uit dat er iets met libresolv op Haiku is dat ook in libnetwork zit. Blijkbaar moet ik de code verder aanpassen. Ik moet erover nadenken...
find . -type f -exec sed -i -e 's|lresolv|lnetwork|g' {} ;De eeuwige vraag: wat gebeurt er?
/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 foundHetzelfde, alleen dan in profiel. Gegoogeld en . Als ik toevoeg -lssp helpt 'soms', ik probeer:
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp"
(...)/Haiku/home/tmate> make
(...)/Haiku/home/tmate> ./tmateHé, het start op! Maar...
[tmate] ssh.tmate.io lookup failure. Reattempt in 2 seconden (niet-herstelbare fout in naamresolutie)Ik probeer te debuggen, :
/Haiku/home/tmate> strace -f ./tmate >log 2>&1‘Bad port ID’ - dit is al een visitekaartje . Misschien heeft iemand een idee wat er mis is en hoe dit op te lossen? Als dat het geval is, zal ik het artikel bijwerken. Link naar .
Het porteren van een GUI-applicatie naar Qt.
Ik kies een eenvoudige QML-applicatie.
/> 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 eenvoudig. Minder dan een minuut!
Applicaties verpakken in hpkg met behulp van haikuporter en haikuports.
Waar te beginnen? Er is geen eenvoudige documentatie, ik ga naar het kanaal #haiku op irc.freenode.net en hoor:
- Opdracht
package— een low-level manier om pakketten te maken. Over het algemeen is PackageInfo voldoende, zoals beschreven in de sectie 'Het in een goed .hpkg-pakket maken' - Ik moet iets doen
- Je kunt gebruiken (het valt uit, )
Ik weet niet wat ik moet doen. Ik denk dat ik een beginnershandleiding nodig heb, zoals 'Hallo Wereld!', idealiter een video. Het zou ook nuttig zijn om een gemakkelijk in te voeren introductie tot HaikuPorter te krijgen, zoals gedaan in GNU hello.
Ik lees het volgende:
haikuporteris een tool voor het maken van algemene pakketprojecten voor Haiku. Het gebruikt de HaikuPorts-repository als basis voor alle pakketten. Voor het maken van pakketten worden haikuporter-recepten gebruikt.
Daarnaast leer ik dat:
Er is geen noodzaak om recepten in de HaikuPorts-opslagplaats te houden. Je kunt een andere repository maken, recepten daarin plaatsen en haikuporter ernaar verwijzen.
Dat is precies wat ik nodig heb — als ik niet naar manieren zoek om het pakket publiekelijk te hosten. Maar dat is een onderwerp voor een andere post.
Installatie van haikuporter en 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/ # maak het vanaf elke locatie uitvoerbaar
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.confRecept schrijven
SUMMARY="Demo QtQuick-applicatie"
DESCRIPTION="QtQuickApp is een demo QtQuick-applicatie voor het testen van Haiku-portering en -verpakking"
HOMEPAGE="https://github.com/probonopd/QtQuickApp"
COPYRIGHT="Geen"
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
}Recept bouwen
Ik sla het bestand op onder de naam QtQuickApp-1.0.recipe, waarna ik het volgende uitvoer haikuporter -S ./QuickApp-1.0.recipe. Afhankelijkheden voor alle pakketten in de repository worden gecontroleerd , wat enige tijd in beslag neemt. Ik ga even koffie drinken.
En waarom zou deze controle op mijn lokale machine moeten plaatsvinden en niet centraal op de server één keer voor iedereen?
According to mr. waddlesplash:
Omdat het mogelijk is om elk bestand in de repository te herschrijven 😉 Je kunt dit een beetje optimaliseren door de benodigde informatie te berekenen wanneer dat nodig is, omdat de laatste wijzigingen vrij zeldzaam zijn.
~/QtQuickApp> haikuporter QtQuickApp-1.0.recipe
Controleren of er afhankelijkheidsinformatie moet worden bijgewerkt ...
Zoeken naar verouderde afhankelijkheidsinformatie ...
Fout: QtQuickApp niet gevonden in de repositoryBlijkbaar bestaat er geen eenvoudig receptbestand met de broncode van uw applicatie. Het moet in een repository in HaikuPorts-formaat worden bewaard.
~\/QtQuickApp> mv QtQuickApp-1.0.recipe ..\/haikuports\/app-misc\/QtQuickApp\/\n~\/QtQuickApp> ..\/haikuport\n~\/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipeDit feit maakt de build omslachtiger. Ik vind het niet erg leuk, maar ik denk dat het nodig is zodat uiteindelijk alle open-source software in HaikuPorts verschijnt.
Ik ontvang het volgende:
~\/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe\nControleer of er afhankelijkheidsinformatie moet worden bijgewerkt ...\n afhankelijkheidsinformatie van QtQuickApp-1.0 bijwerken\nZoeken naar verouderde afhankelijkheidsinformatie ...\nFout: QtQuickApp-1.0.recipe niet gevonden in de tree.Wat is er aan de hand? Na het lezen van irc doe ik:
~\/QtQuickApp> haikuporter -S QtQuickApp\nControleer of er afhankelijkheidsinformatie moet worden bijgewerkt ...\n afhankelijkheidsinformatie van QtQuickApp-1.0 bijwerken\nZoeken naar verouderde afhankelijkheidsinformatie ...\n----------------------------------------------------------------------\napp-misc::QtQuickApp-1.0\n \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe\n----------------------------------------------------------------------Downloading: https:\/\/github.com\/probonopd\/QtQuickApp.git ...\n--2019-07-14 16:12:44-- https:\/\/github.com\/probonopd\/QtQuickApp.git\nResolving github.com... 140.82.118.3\nConnecting to github.com|140.82.118.3|:443... verbonden.\nHTTP-verzoek verzonden, wacht op antwoord... 301 Permanent Verhuist\nLocatie: https:\/\/github.com\/probonopd\/QtQuickApp [volgend]\n--2019-07-14 16:12:45-- https:\/\/github.com\/probonopd\/QtQuickApp\nHernoem bestaande verbinding met github.com:443.\nHTTP-verzoek verzonden, wacht op antwoord... 200 OK\nLengte: niet gespecificeerd [text\/html]\nOpslaan in: ‘\/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git’\n 0K . 1.34M=0.06s\n2019-07-14 16:12:45 (1.34 MB\/s) - ‘\/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git’ opgeslagen [90094]\nControle van de checksum van QtQuickApp.git\nWaarschuwing: ----- CHECKSUM TEMPLATE -----\nWaarschuwing: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"\nWaarschuwing: -----------------------------\nFout: Geen checksum gevonden in het recept!Er is een interessante vraag opgekomen. Als ik een checksum aan het recept toevoeg — zal deze dan overeenkomen met de laatste git-commit voor continue integratie? (De ontwikkelaar bevestigt: "Het zal niets worden. Recepten zijn ontworpen om relatief stabiel te zijn").
Voor de grap voegen ze toe aan het recept:
CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"Dit blijft niet bevredigend:
~\/QtQuickApp> haikuporter -S QtQuickApp\nControleer of er afhankelijkheidsinformatie moet worden bijgewerkt ...\n afhankelijkheidsinformatie van QtQuickApp-1.0 bijwerken\nZoeken naar verouderde afhankelijkheidsinformatie ...\n----------------------------------------------------------------------\napp-misc::QtQuickApp-1.0\n \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe\n----------------------------------------------------------------------\nOvergeslagen downloaden van bron voor QtQuickApp.git\nValideren van de checksum van QtQuickApp.git\nBron van QtQuickApp.git uitpakken\nFout: Onbekend archieftype in bestand \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.gitWaarom gebeurt dit? Dit is immers een git-repository, de code staat er al rechtstreeks, er is niets uit te pakken. Vanuit mijn perspectief moet de tool slim genoeg zijn om geen unpacker te zoeken wanneer hij met een GitHub-URL werkt.
Misschien werkt het met uri git://
SOURCE_URI="git://github.com/probonopd/QtQuickApp.git"Nu klaagt het zo:
Downloading: git://github.com/probonopd/QtQuickApp.git ...
Fout: Downloaden van onveilige bronnen is uitgeschakeld in haikuports.conf!Hmmm, waarom is alles zo moeilijk, waarom kan het niet "gewoon werken"? Uiteindelijk is het niet zo zeldzaam om iets van GitHub te bouwen. Het gaat vooral om tools die direct werken, zonder de noodzaak voor instellingen, of zoals ik het noem 'gedoe'.
Misschien werkt het zo:
SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"Nee. Ik krijg nog steeds deze vervelende foutmelding en doe,
sed -i -e 's|#ALLOW_UNSAFE_SOURCES|ALLOW_UNSAFE_SOURCES|g' /boot/home/config/settings/haikuports.confIk ga een beetje verder, maar waarom schreeuwt het naar me (GitHub is toch niet veilig!) en probeert het nog steeds iets uit te pakken.
Volgens :
Ja, de reden was de wens om de integriteit van de gegevens voor de bouw te controleren. Een van de mogelijkheden is het verifiëren van de checksum van het archief, maar je kunt uiteraard ook losse bestanden hashen, wat niet zal worden geïmplementeerd, omdat dit veel meer tijd kost. Dit leidt tot de 'onveiligheid' van git en andere VCS. Waarschijnlijk zal dit altijd zo blijven, omdat het relatief gemakkelijk en vaak sneller is om een archief op GitHub te maken. En in de toekomst zal de foutmelding mogelijk niet zo schreeuwend zijn... (we voeren geen merges van dergelijke recepten meer in HaikuPorts).
~QtQuickApp> haikuporter -S QtQuickApp
Controleren of er updates zijn voor afhankelijkheden ...
Zoeken naar verouderde afhankelijkheid-informatie ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
/boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Downloading: git+https://github.com/probonopd/QtQuickApp.git ...
Waarschuwing: ONVEILIGE BRONNEN ZIJN SLECHT EN MOETEN NIET IN PRODUCTIE WORDEN GEBRUIKT
Waarschuwing: VERPLAATS ZO SNEL MOGELIJK NAAR EEN STATISCH ARCHIEFDOWNLOAD MET CHECKSUM!
Aan het klonen in lege repository '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
Uitpakken van de bron van QtQuickApp.git
tar: /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0: Kan niet openen: Geen dergelijk bestand of directory
tar: Fout kan niet worden hersteld: nu afsluiten
Commando 'git archive HEAD | tar -x -C "/boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0"' gaf een niet-nul exitstatus 2Uit gewoonte vraag ik goede mensen op het #haiku-kanaal in het netwerk irc.freenode.net. En waar zou ik zonder hen zijn? Na een hint begreep ik dat ik moest gebruiken:
srcGitRev="d0769f53639eaffdcd070bddfb7113c04f2a0de8"
SOURCE_URI="https://github.com/probonopd/QtQuickApp/archive/$srcGitRev.tar.gz"
SOURCE_DIR="QtQuickApp-$srcGitRev"
CHECKSUM_SHA256="db8ab861cfec0ca201e9c7b6c0c9e5e828cb4e9e69d98e3714ce0369ba9d9522"Goed, het is duidelijk wat het doet — het downloadt een archief met de broncode van een specifieke revisie. Het lijkt me dom en het is niet helemaal wat ik wilde, precies — de laatste revisie van de masterbranch downloaden.
Een van de ontwikkelaars legde het zo uit:
We hebben onze eigen CI, dus alles wat in de haikuports repository wordt geplaatst, wordt verpakt voor alle gebruikers, en we willen niet het risico lopen om 'alles van de laatste versie in upstream' te verzamelen en te leveren.
Ik begrijp het! In ieder geval kwam het zo uit:
wachten op het bouwen van pakket QtQuickApp-1.0-1 om te worden geactiveerd
wachten op het bouwen van pakket QtQuickApp-1.0-1 om te worden geactiveerd
wachten op het bouwen van pakket QtQuickApp-1.0-1 om te worden geactiveerd
wachten op het bouwen van pakket QtQuickApp-1.0-1 om te worden geactiveerd
wachten op het bouwen van pakket QtQuickApp-1.0-1 om te worden geactiveerd
(...)Het herhaalt dat eindeloos. Blijkbaar is dit een fout (is er een rapport? Ik heb er geen gevonden).
met haikuporter updates-testing Het voelt niet als een 'werkt gewoon' niveau, maar als ontwikkelaar vind ik sommige dingen over werken met Haiku prettig. Het lijkt grotendeels op de Open Build Service — een set tools voor het bouwen van Linux-builds: uiterst krachtig, met een systematische aanpak, maar overbodig voor mijn klein 'hello world' niveau app.
Opnieuw, volgens mr. waddlesplash:
Inderdaad, HaikuPorter is standaard vrij streng (plus er zijn lint-modus en een strenge modus die het nog strenger maken!), maar alleen omdat het pakketten creëert die werken, en niet gewoon pakketten genereert. Daarom klaagt het over niet-verklaarde afhankelijkheden, niet goed geïmporteerde bibliotheken, onjuiste versies, enzovoort. Het doel is om alle problemen, inclusief toekomstige, te vangen voordat de gebruiker het merkt (daarom kon avrdude niet worden geïnstalleerd, want in het recept was feitelijk een afhankelijkheid opgegeven). Bibliotheken zijn niet gewoon aparte pakketten en zelfs geen gedefinieerde SO-versies. HaikuPorter zorgt ervoor dat dit allemaal wordt nageleefd in de recepten zelf om fouten tijdens runtime te voorkomen.
In principe is zo'n striktheid gerechtvaardigd bij het creëren van een besturingssysteem, maar ik vind het te veel voor een 'hello world' applicatie. Ik besloot iets anders uit te proberen.
Applicaties bouwen in hpkg-formaat met het commando 'package create'
Misschien, is een eenvoudige instructie beter voor mij?
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# Zie hieronder als je ook wilt dat de applicatie
# in het menu verschijntOnaangenaam snel, onaangenaam eenvoudig, onaangenaam effectief. Precies zoals ik het leuk vind, geweldig!
Installatie — wat en waar?
Ik heb het bestand QtQuickApp.hpkg verplaatst naar ~/config/packages, met behulp van de bestandsbeheerder, waarna QtQuickApp als bij toverslag verscheen in ~/config/apps.
Weer onaangenaam snel, eenvoudig en effectief. Geweldig, ongelooflijk!
Maar… (waar zou ik zijn zonder ze!)
De applicatie ontbreekt nog steeds in de lijst met applicaties en in QuickLaunch. Ik denk dat ik al weet hoe ik dit kan oplossen. In de bestandsbeheerder verplaats ik QtQuickApp.hpkg van ~/config/packages naar /system/packages.
Nee, nog steeds niet aanwezig. Blijkbaar heb ik (nou ja, en de instructies) iets gemist.
Bij het bekijken van het tabblad "Contents" in HaikuDepot voor enkele andere applicaties zag ik dat er bestanden zijn van het type /data/mimedb/application/x-vnd... wat nog opmerkelijker is, /data/deskbar/menu/Applications/….
Nou, en wat moet ik daar plaatsen? Laat me eens kijken...
mkdir -p data/deskbar/menu/Applications/
( cd data/deskbar/menu/Applications ; ln -s ../../../../../apps/QtQuickApp . )
package add QtQuickApp.hpkg apps dataIk ben er vrij zeker van dat dit trucje zal werken, maar er blijven vragen: waarom is dit nodig, waarvoor is dit nodig? Dit draagt volgens mij bij aan de indruk dat het systeem — zo verfijnd.
Zoals mr. waddlesplash uitlegde:
Soms zijn er applicaties die nodig zijn voor andere applicaties, maar niet in het menu. Bijvoorbeeld, LegacyPackageInstaller in jouw screenshot, die .pkg-archieven in BeOS-formaat verwerkt. Het is de bedoeling dat gebruikers deze installeren, maar hun aanwezigheid in het menu zou verwarring veroorzaken.
Ik heb het gevoel dat er een eenvoudigere oplossing is, bijvoorbeeld Hidden=true in bestanden .desktop op Linux. Waarom zou je niet "verborgen" informatie als een bron en een bestandsattribuut behandelen?
Wat bijzonder niet verfijnd is — de naam van (een) applicatie die het menu toont, deskbar, is hardcoded in het pad.
mr. waddlesplash legt hierover uit:
"Deskbar" moet in dit geval worden begrepen als een algemene term (een beetje zoals "taakbalk", dat zowel naar de Windows-applicatie als naar het algemene concept verwijst). En aangezien dit
deskbar, en niet "Deskbar", kan dit ook op een vergelijkbare manier worden begrepen.
2 "bijna identieke" mappen met applicaties erin
Waarom zijn er 2 mappen met applicaties, en waarom staat mijn QtQuickApplication in de ene en niet in de andere? (Want dit is niet één systeem, maar de tweede is persoonlijk, wat voor mij logisch zou zijn).
Ik ben echt in de war en denk dat dit geünificeerd moet worden.
opmerking van mr. waddlesplash
In de map Apps zijn er applicaties die niet in het menu nodig zijn. Maar de situatie met het menu moet echt verbeterd worden, het moet meer configureerbaar zijn.
Aanvraag, of dit zal niet gebeuren 😉
Ik begon na te denken: is het werkelijk nodig om applicaties te plaatsen in /system/apps, als het voor gebruikers ongewenst is om ze daar te zien? Misschien is het beter om ze ergens anders te plaatsen, waar de gebruiker er niet mee geconfronteerd wordt? Net zoals dit gedaan is in Mac OS X, waar de inhoud van pakketten .app, die niet zichtbaar zou moeten zijn voor de gebruiker in /Applications, wordt verborgen in de diepten van /System/Library/...«`.
Wat betreft afhankelijkheden?
Ik denk dat we op de één of andere manier afhankelijkheden moeten aangeven, toch? Kan Qt als een verplicht onderdeel van de standaardinstallatie van Haiku worden beschouwd? Nee! Qt is standaard niet geïnstalleerd. Kan het pakketbouwprogramma automatisch afhankelijkheden bepalen door ELF-bestanden te controleren? Mij is verteld dat HaikuPorter dit inderdaad doet, maar package nee. Dat komt omdat het gewoon een "pakketbouwer" is die op zich alleen maar bestanden creëert. hpkg.
Moet Haiku verfijnd worden door een beleid toe te voegen waarbij een pakket geen afhankelijkheden mag hebben van pakketten die niet binnen haikuports? (Мне бы так хотелось, поскольку подобная политика значительно облегчает задачу — система смогла бы автоматически разрешить зависимости каждого пакета, загружаемого откуда угодно, без возни с дополнительными источниками пакетов).
mr. waddlesplash legt uit:
We willen de vrijheid van ontwikkelaars niet te veel beperken, want het is duidelijk dat als CompanyX zijn eigen softwarepakket met afhankelijkheden (en dus een repository) wil ondersteunen, ze dat volledig vrij kan doen.
In dat geval zou het misschien verstandig zijn om externe pakketten afhankelijkheden van iets dat niet binnen haikuports valt, te vermijden door alles wat nodig is met de applicatie volledig verpakt. Maar, ik denk dat dit een onderwerp is voor een toekomstige artikel in deze serie. [Is de auteur aan het verwijzen naar AppImage? — opmerking van de vertaler]
Een applicatie-icoon toevoegen
En wat als ik een van de nette ingebouwde iconen aan de bronnen van mijn nieuw gecreëerde applicatie wil toevoegen? Blijkbaar is dit een geweldig onderwerp, dus dit wordt het hoofdonderwerp voor het volgende artikel.
Hoe continue bouw van applicaties organiseren?
Stel je een project voor, vergelijkbaar met Inkscape (ja, ik weet dat het nog niet in Haiku is, maar het is handig om te laten zien). Ze hebben een repository van de broncode. https://gitlab.com/inkscape/inkscape.
Elke keer dat iemand zijn wijzigingen in de repository vastlegt, worden de build-pijplijnen opgestart, waarna de aanpassingen automatisch worden getest, samengesteld en de applicatie wordt verpakt in verschillende pakketten, inclusief AppImage voor Linux (een zelfstandige applicatiepakket dat kan worden gedownload voor lokale tests, ongeacht wat er wel of niet op het systeem geïnstalleerd kan worden). [ik wist het al! — opmerking van de vertaler]). Evenzo gebeurt alles bij elke merge-request, zodat je de applicatie kunt downloaden die is samengesteld uit de code die in de merge-request is voorgesteld, nog voordat deze wordt samengevoegd.
Merge-requests met buildstatussen en de mogelijkheid om gecompileerde binaries te downloaden in geval van een succesvolle build (gemarkeerd met groen).
De build wordt uitgevoerd in Docker-containers. GitLab biedt gratis runners op Linux en bovendien denk ik dat het mogelijk is om je eigen runners aan te sluiten (overigens heb ik geen idee hoe dit zou werken voor systemen zoals Haiku, waarvan ik weet dat ze geen Docker of het equivalent hebben, maar ook voor FreeBSD is er geen Docker, dus dit probleem is niet uniek voor Haiku).
In een ideaal geval zou de build van applicaties voor Haiku binnen een Docker-container voor Linux kunnen worden uitgevoerd. In dit geval kan de build voor Haiku worden geïntegreerd in bestaande pijplijnen. Zijn er cross-compilers? Of moet je de volledige Haiku binnen de Docker-container emuleren, met iets als QEMU/KVM (ervan uitgaand dat het zo zou werken binnen Docker)? Trouwens, veel projecten gebruiken soortgelijke principes. Bijvoorbeeld, Scribus doet dit — het is al beschikbaar voor Haiku. De dag zal komen dat ik dergelijke kan indienen voor andere projecten om ondersteuning voor Haiku toe te voegen.
Een van de ontwikkelaars legt uit:
Voor andere projecten die hun eigen pakketten willen maken, ondersteunt Haiku de gebruikelijke CMake/CPack-methode. Andere buildsystemen kunnen worden ondersteund door het pakketbouwprogramma rechtstreeks aan te roepen, wat goed is als mensen daarin geïnteresseerd zijn. De ervaring leert: tot nu toe is er weinig belangstelling geweest, dus haikuporter werkte zoals het voor ons handig was, maar uiteindelijk moeten beide manieren samenwerken. We zouden een set tools moeten presenteren voor het kruisbouwen van software vanuit Linux of elk ander serverbesturingssysteem (Haiku is niet bedoeld om op servers te draaien).
Staande ovatie. Gewone Linux-gebruikers dragen al deze extra belasting en extra eisen (beveiliging, strikte controle, enz.), die nodig zijn voor een server-besturingssysteem, maar niet voor een persoonlijk besturingssysteem. Daarom ben ik het er volledig mee eens dat de mogelijkheid om applicaties voor Haiku op Linux te bouwen de juiste weg is.
Conclusie
Het porteren van POSIX-applicaties naar Haiku is mogelijk, maar kan meer kosten met zich meebrengen dan een gewone herbouw. Ik zou hier absoluut lang mee bezig zijn geweest, als het niet was voor de hulp van mensen uit het #haiku-kanaal op irc.freenode.net. Maar zelfs zij zagen niet altijd onmiddellijk wat er aan de hand was.
Applicaties geschreven in Qt zijn een gemakkelijke uitzondering. Ik heb een eenvoudige demonstratie-app zonder veel problemen gebouwd.
Het bouwen van pakketten voor eenvoudige applicaties is ook vrij eenvoudig, maar alleen voor "traditioneel vrijgegeven" versies, dat wil zeggen met versie-gearchiveerde broncode die bedoeld is voor ondersteuning in haikuports. Voor continue builds (bouwen bij elke wijziging in GitHub) is het niet zo eenvoudig. Hier voelt Haiku meer aan als een Linux-distributie dan als het resultaat op Mac, waar met één druk op de knop ‘Bouwen’ in XCode een pakket wordt gemaakt. .app, klaar voor invoeging in een schijfimage. .dmg, voorbereid om te worden geüpload naar mijn website.
Continue bouw van applicaties op basis van een ‘server’ besturingssysteem, bijvoorbeeld Linux, zal waarschijnlijk mogelijk worden als er vraag is van ontwikkelaars, maar op dit moment heeft het Haiku-project andere, urgenter taken.
Probeer het zelf! Het Haiku-project biedt imagebestanden voor opstarten vanaf DVD of USB, die dagelijks worden aangemaakt. Voor installatie is het voldoende om het image te downloaden en het op een USB-stick te branden met behulp van
Heb je vragen? We nodigen je uit in ons Russischtalige .
Foutoverzicht:
Vanaf vertaling: dit is het vijfde artikel in de cyclus over Haiku.
Lijst van artikelen:
Bron: habr.com
