TL; DR: Een nieuweling zag Haiku voor het eerst terwijl hij een aantal programma's uit de Linux-wereld probeerde over te zetten.
Mijn eerste Haiku-geporteerde programma, verpakt in het hpkg-formaat
Ik ontdekte Haiku, een verrassend goed besturingssysteem voor pc's.
Vandaag leer ik hoe ik nieuwe programma's naar dit besturingssysteem kan porten. De nadruk ligt vooral op een beschrijving van de eerste ervaring met het overstappen naar Haiku vanuit het standpunt van een Linux-ontwikkelaar. Mijn excuses voor de stomme fouten die ik onderweg heb gemaakt, aangezien het nog geen week geleden is dat ik Haiku voor het eerst heb gedownload.
Ik wil drie doelen bereiken:
- Porteer een eenvoudige CLI-toepassing
- Porteer een applicatie van GUI naar Qt
- Verpak ze vervolgens in hpkg-formaat (aangezien ik nog steeds erover nadenk om AppDir en AppImage voor Haiku aan te passen...)
Laten we beginnen. In secties и , en zo in vanuit HaikuPorts vond ik de goede richting. Er is zelfs een online pdf-boek .
467 pagina's - en dit is uit 1997! Het is eng om naar binnen te kijken, maar ik hoop er het beste van. De woorden van de ontwikkelaar zijn bemoedigend: “het heeft lang geduurd omdat BeOS niet POSIX-compatibel was”, maar Haiku is “grotendeels” al zo.
Een eenvoudige CLI-toepassing overzetten
De eerste gedachte was om de applicatie te porten , maar het bleek dat dit al het geval is een lange tijd geleden.
Eerste poging: niets om naar te kijken
Wat ik niet kan begrijpen, is dat al - ondanks het feit dat het besturingssysteem zelf nog niet eens versie 1.0 is.
Tweede poging: moet herschrijven
Dus ik zal gebruiken , CLI voor het besturen van de Brother P-Touch 770-printer die ik gebruik om labels af te drukken.
Ik print er diverse labels op, en misschien heb je het al gezien in het vorige artikel. Iets eerder schreef ik een klein GUI-wrapperprogramma in Python (aangezien het in Gtk+ is, zal het herschreven moeten worden, en dit is een goede reden om het te leren).
Brother labelprinter P-Touch 770. Werkt het met Haiku?
De Haiku-pakketbeheerder is op de hoogte van bibliotheken en opdrachten, dus als ik het bericht "kan libintl niet vinden" krijg tijdens het uitvoeren configure - Ik lanceer gewoon pkgman install devel:libintl en het vereiste pakket zal worden gevonden. Insgelijks pkgman install cmd:rsync. Nou, enz.
Behalve wanneer 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 Linux-gebaseerd en bestaat het daarom niet voor Haiku. Dat betekent dat ik de broncode die ik probeer te compileren, moet bewerken.
Eh, je kunt niet over je hoofd springen, en ik weet niet eens waar ik moet beginnen.
derde poging
Het zou leuk zijn om te hebben tmate voor Haiku, dan zou ik de Haiku-ontwikkelaars toestaan 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 probeer je het niet 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 curses.
Er is iets gevonden, wat mij een hint gaf voor een competentere vraag:
/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 foundOpnieuw ging ik naar HaikuDepot en vond het natuurlijk devel:msgpack_c_cpp_devel. Wat zijn deze 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 1Bij deze stap besefte ik dat het overzetten van een programma naar Haiku veel meer kennis vereist dan nodig is voor een eenvoudige herbouw.
Ik heb met de vriendelijke Haiku-ontwikkelaars gesproken, het blijkt dat er een bug in msgpack zit, en na een paar minuten zie ik een patch in HaikuPorts. Ik kan met eigen ogen zien hoe het gecorrigeerde pakket is (buildslave - virtuele machines).
Het gecorrigeerde msgpack bouwen op buildmaster
Tussendoor stuur ik een patch naar upstream .
Vijf minuten later is het 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.Onverwacht goed. Is dat wat ik zei?!
Ik keer terug naar het oorspronkelijke probleem:
/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 1Nu lijkt het erop dat msgpack niet de schuld heeft. Ik geef commentaar IMAXLABEL в tty.c als volgt:
tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|/*IMAXBEL|*/ISTRIP);Resultaat:
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.Nou, daar gaan we weer... Trouwens:
/Haiku/home/tmate> ./configure | grep -i OPENAT
checking for openat... novertelt je waar je moet 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.Hier heb ik gepost .
Ze legden me uit dat er naast libresolv op Haiku nog iets anders in libnetwork zit. Kennelijk moet de code nog verder aangepast worden. Moet nadenken…
find . -type f -exec sed -i -e 's|lresolv|lnetwork|g' {} ;De eeuwige vraag: wat is er aan de hand?
/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 in profiel. Googlede en . Als je toevoegt -lssp “Soms” helpt, ik probeer:
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp"
(...)/Haiku/home/tmate> make
(...)/Haiku/home/tmate> ./tmateWauw! Het begint! Maar…
[tmate] ssh.tmate.io lookup failure. Retrying in 2 seconds (non-recoverable failure in name resolution)Ik zal proberen te debuggen :
/Haiku/home/tmate> strace -f ./tmate >log 2>&1“Slechte poort-ID” is al een visitekaartje . Misschien heeft iemand een idee wat er mis is en hoe dit op te lossen is? Als dat zo is, zal ik het artikel bijwerken. Link naar .
De GUI-applicatie overzetten naar Qt.
Ik kies voor 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!Heel eenvoudig. Minder dan een minuut!
Applicaties verpakken in hpkg met behulp van haikuporter en haikuports.
Waar moet ik mee beginnen? Er is geen eenvoudige documentatie, ik ga naar het #haiku-kanaal op irc.freenode.net en hoor:
- Team
package- een manier op laag niveau om pakketten te maken. Voor het grootste deel is PackageInfo voldoende voor haar, zoals beschreven in de sectie "Er een goed .hpkg-pakket van maken" - ik moet iets doen
- Kan gebruiken (bij mij crasht het, )
Het is niet duidelijk wat te doen. Ik denk dat ik een beginnershandleiding in Hello World-stijl nodig heb, idealiter een video. Het zou leuk zijn om ook een handige introductie tot HaikuPorter te hebben, zoals dat gebeurt in GNU hello.
Ik lees het volgende:
haikuporteris een hulpmiddel voor het maken van gemeenschappelijke pakketprojecten voor Haiku. Het gebruikt de HaikuPorts-repository als basis voor alle pakketten. Haikuporter-recepten worden gebruikt om pakketten te maken.
Daarnaast kom ik erachter dat:
Het is niet nodig om recepten op te slaan in de HaikuPorts-opslag. Je kunt nog een repository maken, de recepten daarin plaatsen en vervolgens haikuporter ernaar verwijzen.
Precies wat ik nodig heb - als ik niet op zoek ben naar een manier om het pakket publiekelijk vrij te geven. Maar dit is een onderwerp voor een andere post.
Haikuporter en haikuports installeren
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.confEen recept schrijven
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
}Het recept samenstellen
Ik sla het bestand op onder de naam QtQuickApp-1.0.recipe, waarna ik lanceer aikuporter -S ./QuickApp-1.0.recipe. Afhankelijkheden worden gecontroleerd voor alle pakketten in de repository , wat enige tijd kost. Ik ga wat koffie halen.
Waarom zou deze controle in hemelsnaam op mijn lokale machine moeten worden uitgevoerd, en niet eenmalig centraal op de server?
Volgens dhr. waggelplons:
Hiermee kun je elk bestand in de repository herschrijven. 😉 Je kunt dit een beetje optimaliseren, door de benodigde informatie te berekenen wanneer dat nodig is, omdat de laatst aangebrachte wijzigingen vrij zeldzaam zijn.
~/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 repositoryHet blijkt dat er niet zoiets bestaat als een regulier receptbestand dat de broncode van uw applicatie bevat. U moet het in een repository in het HaikuPorts-formaat bewaren.
~/QtQuickApp> mv QtQuickApp-1.0.recipe ../haikuports/app-misc/QtQuickApp/
~/QtQuickApp> ../haikuport
~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipeDit feit maakt de montage omslachtiger. Ik vind het niet zo leuk, maar ik denk dat het nodig is zodat uiteindelijk alle open source software in HaikuPorts zal verschijnen.
Ik krijg het volgende:
~/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 is er mis? Na het lezen van irc doe ik:
~/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!Er is een interessante vraag gerezen. Als ik een controlesom aan het recept toevoeg, komt deze dan overeen met de laatste git-commit voor continue integratie? (De ontwikkelaar bevestigt: "Het zal niet werken. De recepten zijn ontworpen om relatief stabiel te zijn.")
Voeg voor de lol toe aan het recept:
CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"Nog steeds niet tevreden:
~/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.gitWat is hij aan het doen? Dit is tenslotte een git-repository, de code staat er al direct, er valt niets uit te pakken. Vanuit mijn oogpunt zou de tool slim genoeg moeten zijn om niet naar een uitpakker te zoeken als deze zich boven de GitHub-URL bevindt.
Misschien werkt uri git://
SOURCE_URI="git://github.com/probonopd/QtQuickApp.git"Nu klaagt hij zo:
Downloading: git://github.com/probonopd/QtQuickApp.git ...
Error: Downloading from unsafe sources is disabled in haikuports.conf!Hmm, waarom is alles zo ingewikkeld, waarom kun je niet “gewoon werken”? Het is tenslotte niet zo ongewoon om iets vanuit GitHub te bouwen. Of het nu gaat om tools die meteen werken, zonder dat er instellingen nodig zijn, of zoals ik het "gedoe" noem.
Misschien werkt het zo:
SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"Nee. Ik krijg nog steeds deze rare 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 tegen mij (GitHub is niet veilig!) En probeert nog steeds iets uit te pakken.
Volgens :
Nou ja, de reden was de wens om de integriteit van de ontvangen gegevens voor montage te controleren. Een van de opties is om de checksum van het archief te verifiëren, maar je kunt uiteraard individuele bestanden hashen, wat niet zal worden geïmplementeerd, omdat het duurt veel langer. Het gevolg hiervan is de “onveiligheid” van git en andere VCS. Dit zal hoogstwaarschijnlijk altijd het geval zijn, aangezien het maken van een archief op GitHub vrij eenvoudig en vaak sneller is. Nou ja, in de toekomst zal de foutmelding misschien niet zo opvallend zijn... (we voegen dergelijke recepten niet langer samen in 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 2Uit oude gewoonte vraag ik het aan goede mensen op het #haiku-kanaal op het irc.freenode.net-netwerk. En waar zou ik zijn zonder hen? Na de hint besefte ik dat ik het volgende moest gebruiken:
srcGitRev="d0769f53639eaffdcd070bddfb7113c04f2a0de8"
SOURCE_URI="https://github.com/probonopd/QtQuickApp/archive/$srcGitRev.tar.gz"
SOURCE_DIR="QtQuickApp-$srcGitRev"
CHECKSUM_SHA256="db8ab861cfec0ca201e9c7b6c0c9e5e828cb4e9e69d98e3714ce0369ba9d9522"Oké, het werd duidelijk wat het doet: het downloadt een archief met de broncode van een bepaalde revisie. Het is stom, vanuit mijn standpunt, en niet precies wat ik wilde, namelijk om de laatste revisie van de master branch te downloaden.
Een van de ontwikkelaars legde het zo uit:
We hebben ons eigen CI, dus alles wat in de haikuports-repository wordt geplaatst, wordt voor alle gebruikers verpakt, en we willen niet het risico lopen om “alles upstream in de nieuwste versie” te verzamelen en af te leveren.
Begrepen! Dit is in ieder geval wat er gebeurde:
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
(...)Het herhaalt dit tot in het oneindige. Blijkbaar is dit een fout (bestaat er een applicatie? Ik kon hem niet vinden).
С haikuporter en repository Het heeft niet het gevoel dat het gewoon werkt, maar als ontwikkelaar zijn er een aantal dingen die ik leuk vind aan het werken met Haiku. Voor het grootste deel is het vergelijkbaar met de Open Build Service, een set tools voor het bouwen van Linux-builds: extreem krachtig, met een systematische aanpak, maar overdreven voor mijn kleine "hallo wereld"-applicatie.
Nogmaals, volgens dhr. waggelplons:
HaikuPorter is standaard behoorlijk streng (plus er is zowel een lintmodus als een strikte modus om het nog strenger te maken!), maar alleen omdat het pakketten maakt die werken, in plaats van alleen maar pakketten te maken. Daarom klaagt hij over niet-aangegeven afhankelijkheden, niet correct geïmporteerde bibliotheken, onjuiste versies, enz. Het doel is om alle problemen op te lossen, inclusief toekomstige problemen, voordat de gebruiker er iets van weet (dit is de reden waarom het niet mogelijk was om avrdude te installeren, omdat de afhankelijkheid feitelijk in het recept was gespecificeerd). Bibliotheken zijn niet alleen individuele pakketten of zelfs specifieke SO-versies. HaikuPorter zorgt ervoor dat dit allemaal in de recepten zelf wordt nageleefd om fouten tijdens de uitvoering te voorkomen.
In principe is dit niveau van nauwkeurigheid gerechtvaardigd bij het maken van een besturingssysteem, maar het lijkt mij onnodig voor een “hello world”-applicatie. Ik besloot iets anders te proberen.
Applicaties bouwen in hpkg-formaat met behulp van de opdracht “package create”.
Misschien, Zullen eenvoudige instructies beter voor mij werken?
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 menuOnverwacht snel, onverwacht eenvoudig, onverwacht effectief. Precies zoals ik het graag heb, geweldig!
Installatie - wat en waar?
Het bestand QtQuickApp.hpkg verplaatst naar ~/config/packagesmet behulp van een bestandsbeheerder, waarna QtQuickApp op magische wijze verscheen ~/config/apps.
Opnieuw onverwacht snel, eenvoudig en effectief. Geweldig, ongelooflijk!
Maar... (waar zouden we zijn zonder hen!)
De app ontbreekt nog steeds in de menulijst met apps en QuickLaunch. Ik denk dat ik al weet hoe ik het moet oplossen. In bestandsbeheer verplaats ik QtQuickApp.hpkg van ~/config/packages naar /system/packages.
Nee, nog steeds vermist. Blijkbaar heb ik (nou ja, en de instructies) iets gemist.
Nadat ik naar het tabblad "Inhoud" in HaikuDepot voor enkele andere toepassingen had gekeken, zag ik dat er bestanden zijn zoals /data/mimedb/application/x-vnd... wat nog opmerkelijker is /data/deskbar/menu/Applications/….
Tja, wat moet ik daar zetten? Kom op...
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 deze truc zal werken, maar de vragen blijven: waarom is dit nodig, waar is het voor? Ik denk dat dit de algemene indruk vernietigt dat het systeem zo geavanceerd is.
Zoals uitgelegd door dhr. waggelplons:
Soms zijn er applicaties die andere applicaties nodig hebben, maar die niet in het menu staan. Bijvoorbeeld LegacyPackageInstaller in uw schermafbeelding, waarbij .pkg-archieven in BeOS-indeling worden verwerkt. Ik zou graag willen dat gebruikers ze installeren, maar hun aanwezigheid in het menu zal tot verwarring leiden.
Om de een of andere reden lijkt het mij bijvoorbeeld dat er een eenvoudiger oplossing is Hidden=true in bestanden .desktop op Linux. Waarom zouden we de "verborgen" informatie niet tot een bron en attribuut van het bestandssysteem maken?
Wat vooral niet subtiel is, is de naam van (sommige) applicatie die het menu toont, deskbar, onderweg stevig vastgebonden.
Dhr. Waddlesplash legt dit uit:
“Bureaubalk” moet in dit geval worden opgevat als een soort algemene term (op vrijwel dezelfde manier als “taakbalk”, die verwijst naar zowel de Windows-applicatie als het algemene concept). Nou, sinds dit
deskbar, niet “Deskbar”, dit kan ook op een vergelijkbare manier worden begrepen.
2 "bijna identieke" mappen met applicaties erin
Waarom zijn er twee mappen met toepassingen, en waarom bevindt mijn QtQuickApplication zich in de ene, maar niet in de andere? (Dit is tenslotte niet één systeem, maar een tweede gebruiker, wat voor mij persoonlijk begrijpelijk zou zijn).
Ik ben echt in de war en ik denk dat dit verenigd moet worden.
commentaar van dhr. waggelplons
De Apps-catalogus bevat applicaties die niet nodig zijn in het menu. Maar de situatie met het menu moet echt worden verbeterd, om het beter aanpasbaar te maken.
Solliciteren, anders gebeurt het niet 😉
Ik vroeg me af: is het echt nodig om applicaties in te hosten? /system/apps, als gebruikers ze daar zien, is dat ongewenst. Misschien is het beter om ze op een andere plek te plaatsen waar de gebruiker ze niet tegenkomt? Net zoals het wordt gedaan in Mac OS X, waar de inhoud van pakketten .app, die niet zichtbaar mag zijn voor de gebruiker /Applications, verborgen in de diepten van /System/Library/…“`.
Hoe zit het met afhankelijkheden?
Ik denk dat het de moeite waard is om de afhankelijkheden op de een of andere manier te specificeren, toch? Kan Qt standaard als een verplicht onderdeel van de Haiku-installatie worden beschouwd? Nee! Qt wordt niet standaard geïnstalleerd. Kan een pakketbouwer automatisch afhankelijkheden detecteren door ELF-bestanden te controleren? Er is mij verteld dat HaikuPorter dit daadwerkelijk doet, maar package Nee. Dat komt omdat het slechts een "pakketbouwer" is die zelfstandig bestanden maakt hpkg.
Moet Haiku geavanceerder worden gemaakt door een beleid toe te voegen dat een pakket geen afhankelijkheden mag hebben van pakketten buiten Haiku? haikuports? (Dat zou ik graag willen, omdat een dergelijk beleid de zaken een stuk eenvoudiger zou maken - het systeem zou automatisch de afhankelijkheden kunnen oplossen van elk pakket dat waar dan ook wordt gedownload, zonder te rommelen met extra pakketbronnen.)
Dhr. Waddlesplash legt uit:
We zouden de vrijheid van ontwikkelaars niet zo erg willen beperken, omdat het duidelijk is dat als CompanyX zijn eigen set software met afhankelijkheden (en dus een repository) wil ondersteunen, het dat volledig vrij zal doen.
In dat geval kan het de moeite waard zijn om pakketten van derden aan te bevelen de afhankelijkheid van iets dat niet in haikuports is opgenomen te vermijden door alles wat nodig is volledig in de applicatie te verpakken. Maar ik denk dat dit een onderwerp is voor een toekomstig artikel in deze serie. [Gaat de auteur richting AppImage? — ca. vertaler]
Een applicatiepictogram toevoegen
Wat moet ik doen als ik een van de mooie ingebouwde pictogrammen wil toevoegen aan de bronnen van mijn nieuw gemaakte applicatie? Het blijkt dat dit een geweldig onderwerp is, dus het zal de basis vormen voor het volgende artikel.
Hoe organiseer je continue applicatie-builds?
Stel je een project als Inkscape voor (ja, ik ben me ervan bewust dat het nog niet beschikbaar is in Haiku, maar het is handig om het erop weer te geven). Ze hebben een broncoderepository https://gitlab.com/inkscape/inkscape.
Elke keer dat iemand zijn wijzigingen in de repository vastlegt, worden er build-pijplijnen gelanceerd, waarna de wijzigingen automatisch worden getest en gebouwd, en de applicatie wordt verpakt in verschillende pakketten, waaronder AppImage voor Linux (een zelfstandig applicatiepakket dat kan worden gedownload voor lokaal testen, ongeacht wat wel of niet op het systeem kan worden geïnstalleerd [Ik wist het! — ca. vertaler]). Hetzelfde gebeurt bij elk samenvoegverzoek van een vertakking, dus u kunt de applicatie downloaden die is gebouwd op basis van de code die in het samenvoegverzoek wordt voorgesteld voordat u gaat samenvoegen.
Voeg verzoeken samen met buildstatussen en de mogelijkheid om de gecompileerde binaire bestanden te downloaden als de build succesvol is (groen gemarkeerd)
De build wordt uitgevoerd in Docker-containers. GitLab biedt gratis runners op Linux, en ik denk dat het mogelijk zou kunnen zijn om je eigen runners op te nemen (ik zie overigens niet in hoe dit zou werken voor systemen als Haiku, waarvan ik weet dat ze geen Docker of gelijkwaardig hebben, maar ook voor FreeBSD is er geen Docker, dus dit probleem is niet uniek voor Haiku).
Idealiter kunnen Haiku-applicaties worden gebouwd in een Docker-container voor Linux. In deze situatie kan de assemblage voor Haiku in bestaande pijpleidingen worden ingebracht. Zijn er cross-compilers? Of moet ik de hele Haiku emuleren in een Docker-container met behulp van zoiets als QEMU/KVM (ervan uitgaande dat het op die manier zal werken in Docker)? Overigens gebruiken veel projecten vergelijkbare principes. Scribus doet dit bijvoorbeeld: het is al beschikbaar voor Haiku. Er komt een dag dat ik kan versturen Trek verzoeken naar andere projecten om Haiku-ondersteuning toe te voegen.
Een van de ontwikkelaars legt uit:
Voor andere projecten die zelf pakketten willen maken, wordt de reguliere CMake/CPack-methode ondersteund. Andere bouwsystemen kunnen worden ondersteund door het bouwprogramma van het pakket rechtstreeks aan te roepen, wat prima is als mensen erin geïnteresseerd zijn. De ervaring leert: tot nu toe was er niet veel belangstelling, dus haikuporter werkte voor ons net zo handig, maar uiteindelijk zouden beide methoden moeten samenwerken. We zouden een set tools moeten introduceren voor het cross-building van software van Linux of een ander serverbesturingssysteem (Haiku is niet ontworpen om op servers te draaien).
Ik geef een staande ovatie. Gewone Linux-gebruikers dragen al deze extra lasten en extra bagage (beveiliging, strikte controle, enz.) met zich mee die nodig is voor een serverbesturingssysteem, maar niet voor een persoonlijk besturingssysteem. Dus ik ben het er volledig mee eens dat het de juiste keuze is om Haiku-apps op Linux te kunnen bouwen.
Conclusie
Het overbrengen van POSIX-applicaties naar Haiku is mogelijk, maar kan duurder zijn dan een typische herbouw. Ik zou hier zeker lang mee vastzitten als er niet de hulp was van mensen van het #haiku-kanaal op het irc.freenode.net-netwerk. Maar zelfs zij zagen niet altijd meteen wat er aan de hand was.
Applicaties geschreven in Qt vormen een gemakkelijke uitzondering. Ik heb zonder problemen een eenvoudige demo-applicatie samengesteld.
Het bouwen van een pakket voor eenvoudige applicaties is ook vrij eenvoudig, maar alleen voor “traditioneel uitgebrachte” applicaties, d.w.z. met versiebeheer van broncode-archieven bedoeld voor ondersteuning in haikuports. Voor een continue build (build voor elke commit van wijzigingen) met GitHub lijkt alles niet zo eenvoudig. Hier voelt Haiku meer als een Linux-distributie dan als het resultaat op een Mac, waar je, als je op de knop "Build" in XCode klikt, een pakket krijgt .app, klaar om in een schijfkopie te worden ingevoegd .dmg, klaar om te downloaden op mijn website.
Het continu bouwen van applicaties op basis van een 'server'-besturingssysteem, bijvoorbeeld Linux, zal hoogstwaarschijnlijk mogelijk worden als er vraag is van ontwikkelaars, maar op dit moment heeft het Haiku-project andere, urgentere taken.
Probeer het zelf! Het Haiku-project levert immers gegenereerde afbeeldingen voor het opstarten vanaf dvd of USB . Om te installeren hoeft u alleen maar de afbeelding te downloaden en deze naar een flashstation te schrijven met behulp van
Heb je nog vragen? Wij nodigen u uit voor de Russischtalige .
Foutoverzicht:
Van vertaling: dit is het vijfde artikel in de serie over Haiku.
Lijst met artikelen:
Bron: www.habr.com