Min femte dag med Haiku: lÄt oss porta nÄgra program
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
nyligen 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 dokumentationen О utveckling, sÄvÀl som i wiki frÄn HaikuPorts hittade jag rÀtt riktning. Det finns till och med en PDF-bok online BeOS: Portera en Unix-applikation.
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 avrdude, men som det visade sig Àr det redan det har gjort för lÀnge sedan.
SÄ jag ska anvÀnda ptouch-770, 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 found
Kanske À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 install
Ser 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 found
I 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 1
I 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 gÄr hit (buildslave - virtuella maskiner).
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 1
Nu ser det ut som att det inte Ă€r fel pĂ„ msgpack. Jag kommenterar IMAXLABEL ĐČ tty.c sĂ„ hĂ€r:
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... no
/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.
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 found
Samma sak, bara i profil. Googlade och hittade detta. 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> ./tmate
Wow! Det börjar! MenâŠ
[tmate] ssh.tmate.io lookup failure. Retrying in 2 seconds (non-recoverable failure in name resolution)
/> 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"
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.conf
Att 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 haikuports, 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 repository
Det 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.
Detta 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.")
~/QtQuickApp> haikuporter -S QtQuickApp
Checking if any dependency-infos need to be updated ...
updating dependency infos of QtQuickApp-1.0
Looking for stale dependency-infos ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
/boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------
Skipping download of source for QtQuickApp.git
Validating checksum of QtQuickApp.git
Unpacking source of QtQuickApp.git
Error: Unrecognized archive type in file /boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git
Vad 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.
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".
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 2
Av 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:
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 haikuports 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, detta 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 menu
OvÀ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 data
Jag À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 sÄdana 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 dagligen. För att installera, ladda bara ner bilden och skriv den till en flashenhet med hjÀlp av Etcher
Har du nÄgra frÄgor? Vi inbjuder dig till den rysktalande telegramkanal.