TL; DR: En nybörjare såg Haiku för första gången som försökte porta några program från Linux-världen.
Mitt första Haiku-porterade program, förpackat i sitt hpkg-format
Jag upptäckte Haiku, ett förvånansvärt bra operativsystem för PC.
Idag ska jag lära mig hur man portar nya program till det här operativsystemet. Huvudfokus är en beskrivning av den första upplevelsen av att byta till Haiku från en Linux-utvecklares synvinkel. Jag ber om ursäkt för alla dumma misstag jag gjort på vägen, eftersom det inte ens har gått en vecka sedan jag laddade ner Haiku första gången.
Jag vill uppnå tre mål:
- Portera en enkel CLI-applikation
- Portera en applikation från GUI till Qt
- Packa dem sedan i hpkg-format (eftersom jag fortfarande funderar på att anpassa AppDir och AppImage för Haiku...)
Låt oss börja. I avsnitt и , såväl som i från HaikuPorts hittade jag rätt riktning. Det finns till och med en PDF-bok online .
467 sidor - och det här är från 1997! Det är läskigt att titta in, men jag hoppas på det bästa. Utvecklarens ord är uppmuntrande: "det tog lång tid eftersom BeOS inte var POSIX-kompatibelt", men Haiku "för det mesta" är redan så.
Portera en enkel CLI-applikation
Den första tanken var att porta applikationen , men som det visade sig är det redan det för länge sedan.
Första försöket: inget att titta på
Det jag inte kan förstå är det redan – trots att själva operativsystemet inte ens är version 1.0 än.
Andra försöket: behöver skriva om
Så jag ska använda , CLI för att styra Brother P-Touch 770-skrivaren som jag använder för att skriva ut etiketter.
Jag trycker olika etiketter på den, och du kanske redan har sett den i föregående artikel. Lite tidigare skrev jag ett litet GUI-omslagsprogram i Python (eftersom det är i Gtk+ måste det skrivas om, och detta är en bra anledning att lära sig).
Brother P-Touch 770 etikettskrivare Fungerar den med Haiku?
Haiku-pakethanteraren känner till bibliotek och kommandon, så om jag får meddelandet "kan inte hitta libintl" när jag kör configure – Jag startar precis pkgman install devel:libintl och det nödvändiga paketet kommer att hittas. likaså pkgman install cmd:rsync. Tja osv.
Förutom när detta inte fungerar:
/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 foundKanske är udev för Linux-baserat och existerar därför inte för Haiku. Vilket betyder att jag måste redigera källkoden jag försöker kompilera.
Eh, du kan inte hoppa över huvudet, och jag vet inte ens var jag ska börja.
Tredje försöket
Det skulle vara trevligt att ha tmate för Haiku skulle jag tillåta Haiku-utvecklarna att ansluta till min terminalsession - om något skulle gå fel. Instruktionerna är ganska enkla:
./autogen.sh
./configure
make
make installSer bra ut, så varför inte prova det på 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 foundI detta steg öppnar jag HaikuDepot och söker curses.
Något hittades, som gav mig en ledtråd för en mer kompetent fråga:
/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Återigen gick jag till HaikuDepot, och, naturligtvis, hittade devel:msgpack_c_cpp_devel. Vad är dessa konstiga namn?
/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 1I det här steget insåg jag att portering av ett program till Haiku kräver mycket mer kunskap än vad som behövs för en enkel ombyggnad.
Jag pratade med de vänliga Haiku-utvecklarna, det visar sig att det finns en bugg i msgpack, och efter några minuter ser jag en patch i HaikuPorts. Jag kan se med mina egna ögon hur det korrigerade paketet (buildslave - virtuella maskiner).
Bygger det korrigerade msgpacket på buildmaster
Däremellan skickar jag en patch till uppströms .
Fem minuter senare är det uppdaterade msgpacket redan tillgängligt i 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.Oväntat bra. Var det det jag sa?!
Jag återgår till det ursprungliga problemet:
/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 ser det ut som att det inte är fel på msgpack. Jag kommenterar IMAXLABEL в tty.c så här:
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.Nåväl, nu kör vi igen... Förresten:
/Haiku/home/tmate> ./configure | grep -i OPENAT
checking for openat... noberättar var du ska gräva:
/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.Här postade jag .
De förklarade för mig att det finns något annat i libnetwork förutom libresolv på Haiku. Tydligen måste koden redigeras ytterligare. Måste tänka...
find . -type f -exec sed -i -e 's|lresolv|lnetwork|g' {} ;Den eviga frågan: vad är det som händer?
/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 foundSamma sak, bara i profil. Googlade och . Om du lägger till -lssp "ibland" hjälper, jag försöker:
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp"
(...)/Haiku/home/tmate> make
(...)/Haiku/home/tmate> ./tmateWow! Det börjar! Men…
[tmate] ssh.tmate.io lookup failure. Retrying in 2 seconds (non-recoverable failure in name resolution)Jag ska försöka felsöka :
/Haiku/home/tmate> strace -f ./tmate >log 2>&1"Bad port ID" är redan som ett visitkort . Kanske någon har en idé om vad som är fel och hur man fixar det? I så fall uppdaterar jag artikeln. Anknyta till .
Portera GUI-applikationen till Qt.
Jag väljer en enkel QML-applikation.
/> 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!Riktigt enkelt. Mindre än en minut!
Förpackningsapplikationer i hpkg med haikuporter och haikuports.
Vad ska jag börja med? Det finns ingen enkel dokumentation, jag går till #haiku-kanalen på irc.freenode.net och hör:
- Team
package- ett sätt att skapa paket på låg nivå. För det mesta räcker PackageInfo för henne, som beskrivs i avsnittet "Göra det till ett riktigt .hpkg-paket" - jag behöver göra något
- Kan använda (det kraschar för mig, )
Det är inte klart vad man ska göra. Jag antar att jag behöver en nybörjarguide i Hello World-stil, helst en video. Det skulle vara trevligt att också ha en bekväm introduktion till HaikuPorter, som görs i GNU hello.
Jag läser följande:
haikuporterär ett verktyg för att skapa gemensamma paketprojekt för Haiku. Den använder HaikuPorts repository som bas för alla paket. Haikuporter-recept används för att skapa paket.
Dessutom får jag reda på att:
Det finns inget behov av att lagra recept i HaikuPorts förvaring. Du kan skapa ett annat förråd, lägga recepten i det och sedan peka haikuporter på det.
Precis vad jag behöver - om jag inte letar efter ett sätt att offentligt släppa paketet. Men detta är ett ämne för ett annat inlägg.
Installera haikuporter och 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.confAtt skriva ett recept
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
}Montering av receptet
Jag sparar filen under namnet QtQuickApp-1.0.recipe, varefter jag startar aikuporter -S ./QuickApp-1.0.recipe. Beroenden kontrolleras för alla paket i förvaret , vilket tar lite tid. Jag går och tar lite kaffe.
Varför i hela friden ska den här kontrollen göras på min lokala dator, och inte centralt på servern en gång för alla?
Enligt mr. waddlesplash:
Med sådan att du kan skriva om vilken fil som helst i förvaret 😉 Du kan optimera detta lite, beräkna nödvändig information när det behövs, eftersom de senaste ändringarna som görs är ganska sällsynta.
~/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 repositoryDet visar sig att det inte finns något som heter en vanlig receptfil som innehåller din applikations källkod. Du måste förvara den i ett arkiv i HaikuPorts-formatet.
~/QtQuickApp> mv QtQuickApp-1.0.recipe ../haikuports/app-misc/QtQuickApp/
~/QtQuickApp> ../haikuport
~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipeDetta faktum gör monteringen mer besvärlig. Jag gillar det inte speciellt, men jag tror att det är nödvändigt för att så småningom all öppen källkod ska dyka upp i HaikuPorts.
Jag får följande:
~/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.Vad är fel? Efter att ha läst irc gör jag:
~/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!En intressant fråga har uppstått. Om jag lägger till en kontrollsumma till receptet – kommer den att matcha den senaste git-commiten för kontinuerlig integration? (Utvecklaren bekräftar: "Det kommer inte att fungera. Recepten är designade för att vara relativt stabila.")
För skojs skull, lägg till i receptet:
CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"Fortfarande inte nöjd:
~/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.gitVad gör han? Det här är trots allt ett git-förråd, koden finns redan där direkt, det finns inget att packa upp. Ur min synvinkel borde verktyget vara smart nog att inte leta efter en uppackare om det är ovanför GitHub-urln.
Kanske kommer uri git:// att fungera
SOURCE_URI="git://github.com/probonopd/QtQuickApp.git"Nu klagar den så här:
Downloading: git://github.com/probonopd/QtQuickApp.git ...
Error: Downloading from unsafe sources is disabled in haikuports.conf!Hmm, varför är allt så komplicerat, varför kan du inte "bara jobba"? Det är trots allt inte så ovanligt att bygga något från GitHub. Oavsett om det är verktyg som fungerar direkt, utan behov av inställningar, eller som jag kallar det "tjafs".
Kanske kommer det att fungera så här:
SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"Nej. Jag får fortfarande det här konstiga felet och gör,
sed -i -e 's|#ALLOW_UNSAFE_SOURCES|ALLOW_UNSAFE_SOURCES|g' /boot/home/config/settings/haikuports.confJag går lite längre, men varför skriker den åt mig (GitHub är inte säker!) och försöker fortfarande packa upp något.
Enligt :
Tja, ja, anledningen var önskan att kontrollera integriteten hos de data som togs emot för montering. Ett av alternativen är att verifiera kontrollsumman för arkivet, men du kan naturligtvis hasha enskilda filer, som inte kommer att implementeras, eftersom det tar mycket längre tid. Konsekvensen av detta är "osäkerheten" hos git och andra VCS. Detta kommer med största sannolikhet alltid att vara fallet, eftersom att skapa ett arkiv på GitHub är ganska enkelt och ofta snabbare. Tja, i framtiden kanske felmeddelandet inte kommer att vara så flashigt... (vi slår inte längre ihop sådana recept i 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 2Av gammal vana går jag och frågar bra människor på #haiku-kanalen på irc.freenode.net-nätverket. Och var skulle jag vara utan dem? Efter tipset insåg jag att jag borde använda:
srcGitRev="d0769f53639eaffdcd070bddfb7113c04f2a0de8"
SOURCE_URI="https://github.com/probonopd/QtQuickApp/archive/$srcGitRev.tar.gz"
SOURCE_DIR="QtQuickApp-$srcGitRev"
CHECKSUM_SHA256="db8ab861cfec0ca201e9c7b6c0c9e5e828cb4e9e69d98e3714ce0369ba9d9522"Okej, det blev tydligt vad det gör - det laddar ner ett arkiv med källkoden för en viss version. Det är dumt, ur min synvinkel, och inte precis vad jag ville, nämligen att ladda ner den senaste versionen från mastergrenen.
En av utvecklarna förklarade det så här:
Vi har vår egen CI, så allt som placeras i haikuports repository kommer att paketeras för alla användare, och vi vill inte riskera att samla in och leverera "allt i den senaste versionen uppströms."
Förstått! Det här är i alla fall vad som hände:
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
(...)Det upprepar detta i oändlighet. Tydligen är detta ett fel (finns det ett program? Jag kunde inte hitta det).
С haikuporter och förvar Det har inte en "bara fungerar"-känsla över sig, men som utvecklare finns det några saker jag gillar med att arbeta med Haiku. För det mesta liknar den Open Build Service, en uppsättning verktyg för att bygga Linux-byggen: extremt kraftfull, med ett systematiskt tillvägagångssätt, men överdrivet för min lilla "hej världen"-applikation.
Återigen, enligt mr. waddlesplash:
Faktum är att HaikuPorter är ganska strikt som standard (plus det finns ett lint-läge såväl som ett strikt läge för att göra det ännu mer strikt!), men bara för att det skapar paket som kommer att fungera, snarare än att bara skapa paket. Det är därför han klagar på odeklarerade beroenden, bibliotek som inte importerats korrekt, felaktiga versioner osv. Målet är att fånga alla problem, inklusive framtida, innan användaren vet om det (det är därför det inte var möjligt att installera avrdude, eftersom beroendet faktiskt specificerades i receptet). Bibliotek är inte bara enskilda paket eller ens specifika SO-versioner. HaikuPorter ser till att allt detta observeras i själva recepten för att undvika fel under utförandet.
I princip är denna rigoritetsnivå motiverad när man skapar ett operativsystem, men det verkar onödigt för mig för en "hej världen"-applikation. Jag bestämde mig för att prova något annat.
Bygg applikationer i hpkg-format med kommandot "package create".
Kanske, Kommer enkla instruktioner att fungera bättre för mig?
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 menuOväntat snabbt, oväntat enkelt, oväntat effektivt. Precis som jag gillar det, fantastiskt!
Installation - vad och var?
Flyttade filen QtQuickApp.hpkg till ~/config/packagesmed en filhanterare, varefter QtQuickApp magiskt dök upp i ~/config/apps.
Återigen, oväntat snabbt, enkelt och effektivt. Underbart, otroligt!
Men... (var skulle vi vara utan dem!)
Appen saknas fortfarande i appmenylistan och QuickLaunch. Jag tror att jag redan vet hur man fixar det. I filhanteraren flyttar jag QtQuickApp.hpkg från ~/config/packages till /system/packages.
Nej, saknas fortfarande. Tydligen har jag (och instruktionerna) missat något.
Efter att ha tittat på fliken "Innehåll" i HaikuDepot för några andra applikationer såg jag att det finns filer som /data/mimedb/application/x-vnd... vad som är ännu mer anmärkningsvärt är /data/deskbar/menu/Applications/….
Tja, vad ska jag lägga där? Kom igen...
mkdir -p data/deskbar/menu/Applications/
( cd data/deskbar/menu/Applications ; ln -s ../../../../apps/QtQuickApp . )
package add QtQuickApp.hpkg apps dataJag är ganska säker på att det här tricket kommer att fungera, men frågorna kvarstår: varför är detta nödvändigt, vad är det till för? Jag tror att detta förstör helhetsintrycket av att systemet är så sofistikerat.
Som förklarat av Mr. waddlesplash:
Ibland finns det applikationer som andra applikationer behöver men som inte finns i menyn. Till exempel LegacyPackageInstaller i din skärmdump, bearbetar .pkg-arkiv i BeOS-format. Jag skulle vilja att användarna installerar dem, men deras närvaro i menyn kommer att leda till förvirring.
Av någon anledning verkar det som att det finns en enklare lösning, till exempel Hidden=true i filer .desktop på Linux. Varför inte göra den "dolda" informationen till en resurs och ett attribut för filsystemet?
Vad som är speciellt inte subtilt är namnet på (något) program som visar menyn, deskbar, styvt knuten längs vägen.
herr. waddlesplash förklarar detta:
"Skrivbordsfält" i det här fallet ska förstås som en slags allmän term (i stort sett på samma sätt som "uppgiftsfältet", som syftar på både Windows-applikationen och det allmänna konceptet). Tja, sedan detta
deskbar, inte "Deskbar", detta kan också förstås på liknande sätt.
2 "nästan identiska" kataloger med applikationer i dem
Varför finns det två kataloger med applikationer, och varför finns min QtQuickApplication i den ena, men inte i den andra? (Detta är trots allt inte ett system ett, utan en andra användare, vilket skulle vara förståeligt för mig personligen).
Jag är verkligen förvirrad och jag tycker att det här borde förenas.
kommentar av mr. waddlesplash
Appkatalogen innehåller applikationer som inte behövs i menyn. Men situationen med menyn måste verkligen förbättras för att göra den mer anpassningsbar.
Ansökan, annars händer det inte 😉
Jag undrade: är det verkligen nödvändigt att vara värd för applikationer /system/apps, om användare ser dem där är det inte önskvärt. Kanske vore det bättre att placera dem på ett annat ställe där användaren inte kommer att stöta på dem? Precis som det görs i Mac OS X, där innehållet i paket .app, som inte ska vara synligt för användaren i /Applications, gömmer sig i djupet av /System/Library/…“`.
Hur är det med beroenden?
Jag tycker att det är värt att specificera beroenden på något sätt, eller hur? Kan Qt betraktas som en obligatorisk del av Haiku-installationen som standard? Nej! Qt är inte installerat som standard. Kan en paketbyggare automatiskt upptäcka beroenden genom att kontrollera ELF-filer? Jag fick höra att HaikuPorter faktiskt gör det här, men package Nej. Det beror på att det bara är en "paketbyggare" som bara skapar filer på egen hand hpkg.
Bör Haiku göras mer sofistikerad genom att lägga till en policy att ett paket inte ska ha beroenden av paket utanför Haiku? haikuports? (Jag skulle vilja, eftersom en sådan policy skulle göra saker mycket enklare - systemet skulle automatiskt kunna lösa beroenden för varje paket som laddas ner var som helst, utan att krångla med ytterligare paketkällor.)
herr. waddlesplash förklarar:
Vi skulle inte vilja begränsa utvecklarnas frihet så mycket, eftersom det är uppenbart att om CompanyX vill stödja sin egen uppsättning mjukvara med beroenden (och därmed ett arkiv) kommer det att göra det helt fritt.
I så fall kan det vara värt att rekommendera att tredjepartspaket undviker beroende av allt som inte ingår i haikuports genom att helt paketera allt som behövs med applikationen. Men jag tror att detta är ett ämne för en framtida artikel i den här serien. [Är författaren på väg mot AppImage? - cirka. översättare]
Lägga till en programikon
Vad händer om jag vill lägga till en av de snygga inbyggda ikonerna till resurserna i min nyskapade applikation? Det visar sig att detta är ett fantastiskt ämne, så det kommer att ligga till grund för nästa artikel.
Hur organiserar man kontinuerliga applikationsbyggen?
Föreställ dig ett projekt som Inkscape (ja, jag är medveten om att det ännu inte är tillgängligt i Haiku, men det är bekvämt att visa på det). De har ett källkodsförråd https://gitlab.com/inkscape/inkscape.
Varje gång någon gör sina ändringar i förvaret, lanseras byggpipelines, varefter ändringarna automatiskt testas, byggs och applikationen paketeras i olika paket, inklusive AppImage för Linux (ett fristående applikationspaket som kan laddas ner för lokal testning oavsett vad som kan installeras på systemet eller inte [Jag visste det! - cirka. översättare]). Samma sak händer med varje förfrågan om sammanslagning av grenar, så du kan ladda ner applikationen som är byggd från koden som föreslås i sammanslagningsförfrågan innan du slår samman.
Slå samman förfrågningar med byggstatus och möjligheten att ladda ner de kompilerade binärfilerna om bygget lyckas (markerat med grönt)
Bygget körs i Docker-containrar. GitLab erbjuder gratis löpare på Linux, och jag tror att det kan vara möjligt att inkludera dina egna löpare (förresten, jag ser inte hur detta skulle fungera för system som Haiku, som jag vet inte har Docker eller motsvarande, men även för FreeBSD finns det ingen Docker, så detta problem är inte unikt för Haiku).
Idealiskt kan Haiku-applikationer byggas inuti en Docker-behållare för Linux. I denna situation kan monteringen för Haiku införas i befintliga rörledningar. Finns det korskompilatorer? Eller ska jag emulera all Haiku inuti en Docker-behållare med något som QEMU/KVM (förutsatt att det kommer att fungera på det sättet i Docker)? Förresten, många projekt använder liknande principer. Till exempel gör Scribus detta - det finns redan för Haiku. En dag kommer dagen då jag kan skicka Dra förfrågningar till andra projekt för att lägga till Haiku-stöd.
En av utvecklarna förklarar:
För andra projekt som vill skapa paket själva, stöds den vanliga CMake/CPack-metoden. Andra byggsystem kan stödjas genom att anropa paketets byggprogram direkt, vilket är bra om folk är intresserade av det. Erfarenheten visar: hittills har det inte varit så mycket intresse, så haikuporter fungerade lika bekvämt för oss, men i slutändan borde båda metoderna fungera tillsammans. Vi bör introducera en uppsättning verktyg för korsbyggande programvara från Linux eller något annat serveroperativsystem (Haiku är inte designat för att köras på servrar).
Jag ger en stående ovation. Vanliga Linux-användare bär all denna extra belastning och extra bagage (säkerhet, strikt kontroll, etc.) som är nödvändigt för ett serveroperativsystem, men inte för ett personligt. Så jag håller helt med om att att kunna bygga Haiku-appar på Linux är vägen att gå.
Slutsats
Det är möjligt att porta POSIX-applikationer till Haiku, men det kan vara dyrare än en vanlig ombyggnad. Jag skulle definitivt ha fastnat med det här länge om det inte vore för hjälp från folk från #haiku-kanalen på irc.freenode.net-nätverket. Men inte ens de såg alltid omedelbart vad som var fel.
Ansökningar skrivna i Qt är ett enkelt undantag. Jag satte ihop en enkel demoapplikation utan problem.
Att bygga ett paket för enkla applikationer är också ganska enkelt, men bara för "traditionellt släppta" sådana, d.v.s. ha versionerade källkodsarkiv avsedda för stöd i haikuports. För ett kontinuerligt bygge (byggt för varje commit av förändringar) med GitHub verkar allt inte vara så enkelt. Här känns Haiku mer som en Linux-distribution än resultatet på en Mac, där när du klickar på "Bygg"-knappen i XCode får du ett paket .app, redo att infogas i en diskavbildning .dmg, förberedd för nedladdning på min hemsida.
Kontinuerlig byggande av applikationer baserade på ett "server"-operativsystem, till exempel Linux, kommer med största sannolikhet att bli möjligt om det finns efterfrågan från utvecklare, men just nu har Haiku-projektet andra, mer pressande uppgifter.
Prova själv! När allt kommer omkring ger Haiku-projektet bilder för uppstart från DVD eller USB, genererade . För att installera, ladda bara ner bilden och skriv den till en flashenhet med hjälp av
Har du några frågor? Vi inbjuder dig till den rysktalande .
Felöversikt:
Från översättning: detta är den femte artikeln i serien om Haiku.
Lista över artiklar:
Källa: will.com