TL; DR: In newbie seach Haiku foar it earst, besykje guon programma's fan 'e Linux-wrâld te portearjen.
Myn earste Haiku-ported programma, ferpakt yn har hpkg-formaat
Ik ûntduts Haiku, in ferrassend goed bestjoeringssysteem foar PC's.
Hjoed sil ik leare hoe't jo nije programma's kinne portearje nei dit bestjoeringssysteem. De haadfokus is in beskriuwing fan 'e earste ûnderfining fan it wikseljen nei Haiku út it eachpunt fan in Linux-ûntwikkelder. Ik ferûntskuldigje my foar alle domme flaters dy't ik ûnderweis makke, want it is noch gjin wike lyn dat ik Haiku foar it earst haw downloade.
Ik wol trije doelen berikke:
- Portje in ienfâldige CLI-applikaasje
- Port in applikaasje fan GUI nei Qt
- Pak se dan yn hpkg-formaat (om't ik noch tink oan it oanpassen fan AppDir en AppImage foar Haiku ...)
Litte wy begjinne. Yn seksjes и lykas fan HaikuPorts fûn ik de goeie rjochting. Der is sels in online PDF-boek .
467 siden - en dit is fan 1997! It is eng om nei binnen te sjen, mar ik hoopje op it bêste. De wurden fan 'e ûntwikkelders binne bemoedigend: "it duorre lang om't BeOS net POSIX-kompatibel wie," mar Haiku "foar it grutste part" is al sa.
Porting in ienfâldige CLI-applikaasje
De earste gedachte wie om de applikaasje te portearjen , mar, sa die bliken, dit is al in hiel skoft lyn.
Earste besykjen: neat te sjen
Wat ik net begryp kin is dat al - nettsjinsteande it feit dat it OS sels noch net iens ferzje 1.0 is.
Twadde poging: moatte herskriuwe
Dus ik sil brûke , CLI foar it kontrolearjen fan de Brother P-Touch 770 printer dy't ik brûk om etiketten te printsjen.
Ik printsje ferskate labels derop, en jo hawwe it miskien al sjoen yn it foarige artikel. In bytsje earder skreau ik in lyts GUI-wrapperprogramma yn Python (om't it yn Gtk + is, sil it opnij skreaun wurde moatte, en dit is in goede reden om te learen).
Brother P-Touch 770 label printer Sil it wurkje mei Haiku?
De Haiku-pakketbehearder wit fan biblioteken en kommando's, dus as ik in "kin libintl net fine" berjocht krij by it útfieren configure - Ik lansearje gewoan pkgman install devel:libintl en it fereaske pakket sil fûn wurde. Likegoed pkgman install cmd:rsync. No, ensfh.
Utsein as dit net wurket:
/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 foundMiskien is udev te Linux-basearre en bestiet dêrom net foar Haiku. Wat betsjut dat ik de boarnekoade dy't ik besykje te kompilearjen moat bewurkje.
Eh, do kinst net springe oer dyn holle, en ik wit net iens wêr't te begjinnen.
Tredde poging
It soe moai wêze om te hawwen tmate foar Haiku, dan soe ik de Haiku-ûntwikkelders tastean om te ferbinen mei myn terminalsesje - yn gefal der wat mis giet. De ynstruksjes binne frij simpel:
./autogen.sh
./configure
make
make installSjocht der goed út, dus wêrom net besykje it 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 foundYn dizze stap iepenje ik HaikuDepot en sykje curses.
Der waard wat fûn, wat my in hint joech foar in mear kompetinte fraach:
/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 foundWer ik gie nei HaikuDepot, en, fansels, fûn devel:msgpack_c_cpp_devel. Wat binne dizze frjemde nammen?
/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 1Op dizze stap realisearre ik dat it portearjen fan in programma nei Haiku folle mear kennis fereasket dan nedich is foar in ienfâldige werbou.
Ik praat mei de freonlike Haiku-ûntwikkelders, it docht bliken dat der in brek is yn msgpack, en nei in pear minuten sjoch ik in patch yn HaikuPorts. Ik kin sjen mei myn eigen eagen hoe't it korrizjearre pakket (buildslave - firtuele masines).
Bouwe it korrizjearre msgpack op buildmaster
Tuskentroch stjoer ik in patch streamop .
Fiif minuten letter is it bywurke msgpack al beskikber yn 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.Unferwachts goed. Ha ik dat sein?!
Ik gean werom nei it orizjinele 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 1No liket it derop dat msgpack net de skuld is. Ik jou kommentaar IMAXLABEL в tty.c like this:
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.No ja, hjir geane we wer... Trouwens:
/Haiku/home/tmate> ./configure | grep -i OPENAT
checking for openat... nofertelt jo wêr't jo grave moatte:
/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.Hjir haw ik pleatst .
Se hawwe my útlein dat d'r wat oars is yn libnetwork neist libresolv op Haiku. Blykber moat de koade fierder bewurke wurde. Moat tinke ...
find . -type f -exec sed -i -e 's|lresolv|lnetwork|g' {} ;De ivige fraach: wat bart der?
/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 foundItselde ding, allinnich yn profyl. Googlede en . As jo tafoegje -lssp "soms" helpt, ik besykje:
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp"
(...)/Haiku/home/tmate> make
(...)/Haiku/home/tmate> ./tmateWow! It begjint! Mar…
[tmate] ssh.tmate.io lookup failure. Retrying in 2 seconds (non-recoverable failure in name resolution)Ik sil besykje te debuggen :
/Haiku/home/tmate> strace -f ./tmate >log 2>&1"Bad port ID" is al as in visitekaartsje . Miskien hat immen in idee wat der mis is en hoe it te reparearjen? As dat sa is, sil ik it artikel bywurkje. Link nei .
Porting de GUI applikaasje nei Qt.
Ik kies in ienfâldige QML applikaasje.
/> cd /Haiku/home//Haiku/home> git clone https://github.com/probonopd/QtQuickApp
/Haiku/home/QtQuickApp> qmake .
/Haiku/home/QtQuickApp> make
/Haiku/home/QtQuickApp> ./QtQuickApp # Works!Echt ienfâldich. Minder as in minút!
Ferpakkingsapplikaasjes yn hpkg mei haikuporter en haikuports.
Wêr moat ik mei begjinne? D'r is gjin ienfâldige dokumintaasje, ik gean nei it #haiku-kanaal op irc.freenode.net en hear:
- team
package- in manier op leech nivo om pakketten te meitsjen. Foar it grutste part is PackageInfo genôch foar har, lykas beskreaun yn 'e seksje "It meitsje yn in goed .hpkg-pakket" - Ik moat wat dwaan
- Kin brûkt wurde (it crasht foar my, )
It is net dúdlik wat te dwaan. Ik tink dat ik in begjinnersgids foar Hello World-styl nedich is, ideaal in fideo. It soe moai wêze om ek in handige yntroduksje ta HaikuPorter te hawwen, lykas dien wurdt yn GNU hallo.
Ik lês it folgjende:
haikuporteris in ark foar it meitsjen fan mienskiplike pakketprojekten foar Haiku. It brûkt de HaikuPorts repository as basis foar alle pakketten. Haikuporter-resepten wurde brûkt om pakketten te meitsjen.
Derneist fyn ik út dat:
D'r is gjin needsaak om resepten op te slaan yn HaikuPorts opslach. Jo kinne in oare repository meitsje, de resepten deryn pleatse, en dan haikuporter derop wize.
Krekt wat ik nedich is - as ik net sykje nei in manier om it pakket iepenbier frij te jaan. Mar dit is in ûnderwerp foar in oare post.
Ynstallearje haikuporter en haikuports
cd /boot/home/
git clone https://github.com/haikuports/haikuporter --depth=50
git clone https://github.com/haikuports/haikuports --depth=50
ln -s /boot/home/haikuporter/haikuporter /boot/home/config/non-packaged/bin/ # 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.confIt skriuwen fan in resept
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
}It gearstallen fan it resept
Ik bewarje de triem ûnder de namme QtQuickApp-1.0.recipe, wêrnei't ik lansearje aikuporter -S ./QuickApp-1.0.recipe. Ofhinklikens wurde kontrolearre foar alle pakketten yn 'e repository , dat duorret wat tiid. Ik gean wat kofje.
Wêrom op ierde moat dizze kontrôle dien wurde op myn lokale masine, en net sintraal op de tsjinner ien kear foar elkenien?
Neffens dhr. waddlesplash:
Mei sa'n dat jo elk bestân yn 'e repository opnij skriuwe kinne 😉 Jo kinne dit in bytsje optimalisearje, de nedige ynformaasje berekkenje as it nedich is, om't de lêste feroaringen frij seldsum binne.
~/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 repositoryIt docht bliken dat d'r net sa'n ding is as in gewoan reseptbestân dat de boarnekoade fan jo applikaasje befettet. Jo moatte it bewarje yn in repository yn it HaikuPorts-formaat.
~/QtQuickApp> mv QtQuickApp-1.0.recipe ../haikuports/app-misc/QtQuickApp/
~/QtQuickApp> ../haikuport
~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipeDit feit makket de gearkomste mear omslachtig. Ik fyn it net bysûnder leuk, mar ik tink dat it nedich is, sadat úteinlik alle iepen boarne software yn HaikuPorts ferskynt.
Ik krij it folgjende:
~/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 der mis? Nei it lêzen fan irc doch 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!In nijsgjirrige fraach is ûntstien. As ik in kontrôlesum tafoegje oan it resept - sil it oerienkomme mei de lêste git-commit foar trochgeande yntegraasje? (De ûntwikkelder befêstiget: "It sil net wurkje. De resepten binne ûntwurpen om relatyf stabyl te wêzen.")
Foar wille, tafoegje oan it resept:
CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"Noch net tefreden:
~/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 docht hy? Dit is ommers in git-repository, de koade is der al direkt, d'r is neat om út te pakken. Fanút myn eachpunt soe it ark tûk genôch wêze moatte om net te sykjen nei in unpacker as it boppe de GitHub-url is.
Miskien sil uri git:// wurkje
SOURCE_URI="git://github.com/probonopd/QtQuickApp.git"No klaget it sa:
Downloading: git://github.com/probonopd/QtQuickApp.git ...
Error: Downloading from unsafe sources is disabled in haikuports.conf!Hmm, wêrom is alles sa yngewikkeld, wêrom kinne jo net "gewoan wurkje"? It is ommers net sa ûngewoan om wat te bouwen fan GitHub. Oft it ark is dy't daliks wurkje, sûnder de needsaak foar opset, of sa't ik it "fussing" neam.
Miskien sil it sa wurkje:
SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"Nee. Ik krij noch altyd dizze rare flater en doch,
sed -i -e 's|#ALLOW_UNSAFE_SOURCES|ALLOW_UNSAFE_SOURCES|g' /boot/home/config/settings/haikuports.confIk gean wat fierder, mar wêrom raast it op my (GitHub is net feilich!) En besykje noch wat út te pakken.
Neffens :
No, ja, de reden wie de winsk om de yntegriteit fan 'e gegevens te kontrolearjen dy't ûntfongen binne foar gearkomste. Ien fan 'e opsjes is om de kontrôlesum fan it argyf te ferifiearjen, mar jo kinne fansels yndividuele bestannen hashje, dy't net ymplementearre wurde, om't it duorret folle langer. De konsekwinsje fan dit is de "ûnfeiligens" fan git en oare VCS. Dit sil nei alle gedachten altyd it gefal wêze, om't it meitsjen fan in argyf op GitHub frij maklik en faak flugger is. No, yn 'e takomst sil it flaterberjocht miskien net sa flitsend wêze ... (wy fusearje sokke resepten net mear yn 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 2Ut âlde gewoante gean ik goeie minsken freegje op it #haiku-kanaal op it irc.freenode.net-netwurk. En wêr soe ik sûnder harren wêze? Nei de hint realisearre ik dat ik soe moatte brûke:
srcGitRev="d0769f53639eaffdcd070bddfb7113c04f2a0de8"
SOURCE_URI="https://github.com/probonopd/QtQuickApp/archive/$srcGitRev.tar.gz"
SOURCE_DIR="QtQuickApp-$srcGitRev"
CHECKSUM_SHA256="db8ab861cfec0ca201e9c7b6c0c9e5e828cb4e9e69d98e3714ce0369ba9d9522"Okee, it waard dúdlik wat it docht - it downloadt in argyf mei de boarnekoade fan in bepaalde ferzje. It is dom, fanút myn eachpunt, en net krekt wat ik woe, nammentlik de lêste ferzje fan 'e mastertûke te downloaden.
Ien fan 'e ûntwikkelders ferklearre it op dizze manier:
Wy hawwe ús eigen CI, dus alles dat is pleatst yn 'e haikuports repository sil wurde ferpakt foar alle brûkers, en wy wolle net it risiko sammelje en leverje "alles yn' e lêste ferzje streamop."
Begrepen! Yn alle gefallen is dit wat bard:
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
(...)It werhellet dit ad infinitum. Blykber is dit in flater (is der in applikaasje? Ik koe it net fine).
С haikuporter en repository It hat gjin "gewoan wurket" gefoel, mar as ûntwikkelder binne d'r wat dingen dy't ik leuk fyn oer wurkjen mei Haiku. Foar it grutste part is it fergelykber mei de Open Build Service, in set ark foar it bouwen fan Linux-builds: ekstreem krêftich, mei in systematyske oanpak, mar tefolle foar myn lytse "hallo wrâld" applikaasje.
Wer, neffens dhr. waddlesplash:
Yndied, HaikuPorter is standert frij strang (plus d'r is in lint-modus en ek in strange modus om it noch stranger te meitsjen!), Mar allinich om't it pakketten makket dy't sille wurkje, ynstee fan gewoan pakketten te meitsjen. Dêrom klaget er oer net-ferklearre ôfhinklikens, biblioteken dy't net goed ymportearre binne, ferkearde ferzjes, ensfh. It doel is in fangen alle problemen, ynklusyf takomstige, foar de brûker wit derfan (dêrom wie it net mooglik om te ynstallearjen avrdude, omdat it resept eins spesifisearre in ôfhinklikheid). Biblioteken binne net allinich yndividuele pakketten of sels spesifike SO-ferzjes. HaikuPorter soarget derfoar dat dit alles wurdt waarnommen yn 'e resepten sels om flaters by útfiering te foarkommen.
Yn prinsipe is dit nivo fan strangens rjochtfeardige by it meitsjen fan in bestjoeringssysteem, mar it liket my net nedich foar in applikaasje "hallo wrâld". Ik besleat wat oars te besykjen.
It bouwen fan applikaasjes yn hpkg-formaat mei it kommando "pakket oanmeitsje".
Miskien, Sille ienfâldige ynstruksjes better foar my wurkje?
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 menuUnferwacht fluch, ûnferwacht ienfâldich, ûnferwachts effektyf. Krekt sa't ik it leuk fyn, geweldig!
Ynstallaasje - wat en wêr?
Ferpleatst de QtQuickApp.hpkg triem nei ~/config/packagesmei help fan in triembehearder, wêrnei't QtQuickApp magysk ferskynde yn ~/config/apps.
Nochris, ûnferwacht fluch, ienfâldich en effektyf. Geweldich, ongelooflijk!
Mar... (wêr soene wy sûnder harren wêze!)
De app ûntbrekt noch yn 'e list mei appsmenu en QuickLaunch. Ik tink dat ik al wit hoe te reparearjen. Yn de triembehearder ferpleatse ik QtQuickApp.hpkg fan ~/config/packages nei /system/packages.
Nee, noch mist. Blykber haw ik (goed, en de ynstruksjes) wat miste.
Nei't ik de ljepper "Ynhâld" yn HaikuDepot seach foar guon oare applikaasjes, seach ik dat d'r bestannen binne lykas /data/mimedb/application/x-vnd... wat noch opmerkliker is /data/deskbar/menu/Applications/….
No, wat moat ik dêr sette? Kom op...
mkdir -p data/deskbar/menu/Applications/
( cd data/deskbar/menu/Applications ; ln -s ../../../../apps/QtQuickApp . )
package add QtQuickApp.hpkg apps dataIk bin der wis fan dat dizze trúk sil wurkje, mar de fragen bliuwe: wêrom is dit nedich, wêr is it foar? Ik tink dat dit de algemiene yndruk ferneatiget dat it systeem sa ferfine is.
As útlein troch Mr. waddlesplash:
Soms binne d'r applikaasjes dy't oare applikaasjes nedich binne, mar binne net yn it menu. Bygelyks, LegacyPackageInstaller yn jo skermôfbylding, it ferwurkjen fan .pkg-argiven yn BeOS-formaat. Ik wol graach dat brûkers se ynstallearje, mar har oanwêzigens yn it menu sil liede ta betizing.
Om ien of oare reden liket it my dat der bygelyks in ienfâldiger oplossing is Hidden=true yn triemmen .desktop op Linux. Wêrom meitsje de "ferburgen" ynformaasje net in boarne en attribút fan it bestânsysteem?
Wat foaral net subtyl is, is de namme fan (guon) applikaasje dy't it menu toant, deskbar, stiif bûn lâns de wei.
dhr. waddlesplash ferklearret dit:
"Bureaubalke" yn dit gefal moat wurde begrepen as in soarte fan algemiene term (op folle deselde wize as "taakbalke", dy't ferwiist nei sawol de Windows-applikaasje as it algemiene konsept). No, sûnt dit
deskbar, net "Deskbar", dit kin ek op in fergelykbere wize begrepen wurde.
2 "hast identike" mappen mei applikaasjes deryn
Wêrom binne der 2 mappen mei applikaasjes, en ek wêrom is myn QtQuickApplication yn ien, mar net yn 'e oare? (Dit is ommers net ien systeem ien, mar in twadde brûker, wat foar my persoanlik begryplik wêze soe).
Ik bin echt yn 'e war en ik tink dat dit ferienige wurde moat.
opmerking troch dhr. waddlesplash
De Apps-katalogus befettet applikaasjes dy't net nedich binne yn it menu. Mar de situaasje mei it menu moat echt ferbettere wurde, om it mear oanpasber te meitsjen.
Oanfraach, of it sil net barre 😉
Ik frege my ôf: is it echt nedich om applikaasjes yn te hostjen /system/apps, as brûkers se dêr sjogge, is it net winsklik. Miskien soe it better wêze om se op in oar plak te pleatsen wêr't de brûker se net tsjinkomt? Krekt as it is dien yn Mac OS X, dêr't de ynhâld fan pakketten .app, dy't net sichtber wêze moatte foar de brûker yn /Applications, ferburgen yn 'e djipten fan /System/Library/...“`.
Hoe sit it mei ôfhinklikens?
Ik tink dat it de muoite wurdich is om de ôfhinklikens op ien of oare manier oan te jaan, krekt? Kin Qt wurde beskôge as in ferplichte part fan de Haiku ynstallaasje standert? Nee! Qt is net ynstallearre standert. Kin in pakketbouwer ôfhinklikens automatysk ûntdekke troch ELF-bestannen te kontrolearjen? Ik waard ferteld dat HaikuPorter eins docht dit, mar package Nee. Dat komt om't it gewoan in "pakketbouwer" is dy't gewoan bestannen op har eigen makket hpkg.
Moat Haiku mear ferfine wurde troch in belied ta te foegjen dat in pakket gjin ôfhinklikens moat hawwe fan pakketten bûten Haiku? haikuports? (Ik soe graach wolle, om't sa'n belied dingen in stik makliker meitsje soe - it systeem soe yn steat wêze om automatysk de ôfhinklikens fan elk pakket dat fan oeral is ynladen, op te lossen, sûnder te rommeljen mei ekstra pakketboarnen.)
dhr. waddlesplash ferklearret:
Wy wolle de frijheid fan ûntwikkelders net sa beheine, om't it fanselssprekkend is dat as CompanyX syn eigen set software mei ôfhinklikens (en dus in repository) stypje wol, it dat folslein frij sil dwaan.
Yn dat gefal kin it oan te rieden wêze dat pakketten fan tredden ôfhinklikens foarkomme fan alles dat net yn haikuports is opnommen troch alles dat nedich is mei de applikaasje folslein te ferpakken. Mar ik tink dat dit in ûnderwerp is foar in takomstich artikel yn dizze searje. [Giet de auteur nei AppImage? — ca. oersetter]
In applikaasje-ikoan tafoegje
Wat as ik ien fan 'e kreaze ynboude ikoanen taheakje wol oan 'e boarnen fan myn nij oanmakke applikaasje? It docht bliken dat dit in geweldich ûnderwerp is, dus it sil de basis wêze foar it folgjende artikel.
Hoe kinne jo trochgeande applikaasjebuilden organisearje?
Stel jo in projekt foar lykas Inkscape (ja, ik bin my bewust dat it noch net beskikber is yn Haiku, mar it is handich om derop te sjen). Se hawwe in boarne koade repository https://gitlab.com/inkscape/inkscape.
Elke kear as immen har wizigingen oan it repository ynset, wurde bouwpipelines lansearre, wêrnei't de wizigingen automatysk wurde hifke, boud en de applikaasje yn ferskate pakketten ferpakt, ynklusyf AppImage foar Linux (in standalone applikaasjepakket dat kin wurde downloade foar lokale testen nettsjinsteande wat al of net ynstallearre wurde op it systeem [Ik wist it! — ca. oersetter]). Itselde ding bart mei elk fersyk foar fúzje fan tûken, sadat jo de applikaasje kinne downloade boud fan 'e koade foarsteld yn it fúzjefersyk foardat jo fusearje.
Fersiken fusearje mei bouwstatussen en de mooglikheid om de kompilearre binaries te downloaden as de bou suksesfol is (grien markearre)
De bou rint yn Docker-konteners. GitLab biedt fergese runners op Linux, en ik tink dat it mooglik is om jo eigen runners op te nimmen (troch de manier, ik sjoch net hoe't dit soe wurkje foar systemen lykas Haiku, dy't ik wit dat se gjin Docker of lykweardich hawwe, mar ek foar FreeBSD is d'r gjin Docker, dus dit probleem is net unyk foar Haiku).
Ideal kinne Haiku-applikaasjes wurde boud yn in Docker-kontener foar Linux. Yn dizze situaasje kin de gearstalling foar Haiku ynfierd wurde yn besteande pipelines. Binne der krúskompilers? Of moat ik alle Haiku yn in Docker-kontener emulearje mei soksawat as QEMU / KVM (oannommen dat it sa wurket yn Docker)? Trouwens, in protte projekten brûke ferlykbere prinsipes. Bygelyks, Scribus docht dit - it is al beskikber foar Haiku. Op in dei komt de dei dat ik stjoere kin Trek fersiken nei oare projekten om Haiku-stipe ta te foegjen.
Ien fan 'e ûntwikkelders ferklearret:
Foar oare projekten dy't sels pakketten wolle oanmeitsje, wurdt de reguliere CMake/CPack-metoade stipe. Oare bousystemen kinne wurde stipe troch it bouprogramma fan it pakket direkt te skiljen, wat goed is as minsken deryn ynteressearre binne. De ûnderfining docht bliken: oant no ta is der net folle belangstelling, dus haikuporter wurke sa handich foar ús, mar, úteinlik, beide metoaden moatte wurkje gear. Wy moatte in set ark yntrodusearje foar cross-building software fan Linux of in oar tsjinner bestjoeringssysteem (Haiku is net ûntworpen om te rinnen op servers).
Ik jou in steande ovaasje. Reguliere Linux-brûkers drage al dizze ekstra lading en ekstra bagaazje (feiligens, strikte kontrôle, ensfh.) Dat is nedich foar in tsjinner bestjoeringssysteem, mar net foar in persoanlike. Dat ik bin it der folslein iens dat it kinnen fan Haiku-apps op Linux bouwe de manier is om te gean.
konklúzje
It portearjen fan POSIX-applikaasjes nei Haiku is mooglik, mar kin djoerder wêze dan in typyske werbou. Ik soe hjir grif lang mei sitte as it net wie foar de help fan minsken fan it #haiku-kanaal op it irc.freenode.net-netwurk. Mar sels se seagen net altyd daliks wat der mis wie.
Applikaasjes skreaun yn Qt binne in maklike útsûndering. Ik haw sûnder problemen in ienfâldige demo-applikaasje gearstald.
It bouwen fan in pakket foar ienfâldige applikaasjes is ek frij maklik, mar allinich foar "tradisjoneel frijlitten", d.w.s. hawwende ferzjes fan boarnekoade-argiven bedoeld foar stipe yn haikuports. Foar in trochgeande build (bou foar elke commit fan feroarings) mei GitHub, liket alles net sa ienfâldich te wêzen. Hjir fielt Haiku mear as in Linux-distribúsje dan it resultaat op in Mac, wêr't jo in pakket krije as jo op de knop "Build" yn XCode klikke .app, klear om yn in skiifôfbylding ynfoege te wurden .dmg, taret foar download op myn webside.
Trochrinnende opbou fan applikaasjes basearre op in "server" bestjoeringssysteem, bygelyks Linux, sil nei alle gedachten mooglik wurde as der fraach is fan ûntwikkelders, mar op it stuit hat it Haiku-projekt oare, mear driuwende taken.
Besykje it sels! It Haiku-projekt leveret ommers ôfbyldings foar it opstarten fan DVD of USB, generearre . Om te ynstallearjen, download gewoan de ôfbylding en skriuw it nei in flash drive mei
Hasto noch fragen? Wy noegje jo út foar it Russysk-sprekkende .
Flateroersjoch:
fan oersetting: dit is it fyfde artikel yn de rige oer Haiku.
List fan artikels:
Boarne: www.habr.com