TL; DR: En nybegynder så Haiku for første gang, der forsøgte at portere nogle programmer fra Linux-verdenen.
Mit første Haiku-porterede program, pakket i dets hpkg-format
Jeg opdagede Haiku, et overraskende godt styresystem til pc'er.
I dag vil jeg lære at portere nye programmer til dette operativsystem. Hovedfokus er en beskrivelse af den første oplevelse af at skifte til Haiku fra en Linux-udviklers synspunkt. Jeg undskylder for de dumme fejl jeg har lavet undervejs, da det ikke engang er gået en uge siden jeg første gang downloadede Haiku.
Jeg ønsker at nå tre mål:
- Port en simpel CLI-applikation
- Portér en applikation fra GUI til Qt
- Pak dem derefter i hpkg-format (da jeg stadig overvejer at tilpasse AppDir og AppImage til Haiku...)
Lad os komme igang. I afsnit и , såvel som i fra HaikuPorts fandt jeg den rigtige retning. Der er endda en online PDF-bog .
467 sider - og dette er fra 1997! Det er skræmmende at se indenfor, men jeg håber på det bedste. Udviklerens ord er opmuntrende: "det tog lang tid, fordi BeOS ikke var POSIX-kompatibelt," men Haiku "for det meste" er allerede sådan.
Portering af en simpel CLI-applikation
Den første tanke var at portere applikationen , men som det viste sig, er dette allerede for lang tid siden.
Første forsøg: intet at se
Hvad jeg ikke kan forstå er det allerede - på trods af at selve OS ikke engang er version 1.0 endnu.
Andet forsøg: skal omskrives
Så jeg vil bruge , CLI til styring af Brother P-Touch 770-printeren, som jeg bruger til at udskrive etiketter.
Jeg printer forskellige etiketter på den, og du har måske allerede set den i den forrige artikel. Lidt tidligere skrev jeg et lille GUI wrapper-program i Python (da det er i Gtk+, skal det omskrives, og det er en god grund til at lære).
Brother P-Touch 770 etiketprinter Fungerer den med Haiku?
Haiku-pakkemanageren kender til biblioteker og kommandoer, så hvis jeg får en "kan ikke finde libintl"-meddelelse, når jeg kører configure - Jeg starter lige pkgman install devel:libintl og den nødvendige pakke vil blive fundet. Ligeledes pkgman install cmd:rsync. Nå, osv.
Undtagen når dette ikke virker:
/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 foundMåske er udev for Linux-baseret og eksisterer derfor ikke for Haiku. Hvilket betyder, at jeg skal redigere kildekoden, jeg prøver at kompilere.
Øh, du kan ikke hoppe over hovedet, og jeg ved ikke engang, hvor jeg skal starte.
Tredje forsøg
Det ville være rart at have tmate for Haiku, så ville jeg tillade Haiku-udviklerne at oprette forbindelse til min terminalsession - hvis noget går galt. Instruktionerne er ret enkle:
./autogen.sh
./configure
make
make installSer godt ud, så hvorfor ikke prøve 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 dette trin åbner jeg HaikuDepot og søger curses.
Der blev fundet noget, som gav mig et tip til en mere kompetent forespørgsel:
/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 foundIgen gik jeg til HaikuDepot og fandt selvfølgelig devel:msgpack_c_cpp_devel. Hvad er disse mærkelige navne?
/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 1På dette trin indså jeg, at portering af et program til Haiku kræver meget mere viden, end det er nødvendigt for en simpel genopbygning.
Jeg talte med de venlige Haiku-udviklere, det viser sig, at der er en fejl i msgpack, og efter et par minutter ser jeg en patch i HaikuPorts. Jeg kan se med mine egne øjne, hvordan den rettede pakke (buildslave - virtuelle maskiner).
Opbygning af den rettede msgpack på buildmaster
Ind imellem sender jeg en patch til upstream .
Fem minutter senere er den opdaterede msgpack allerede tilgængelig 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.Uventet godt. Har jeg sagt det?!
Jeg vender tilbage til det oprindelige problem:
/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 ud til, at msgpack ikke er skyld i det. Jeg kommenterer IMAXLABEL в tty.c som dette:
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å, så er vi igang igen... Forresten:
/Haiku/home/tmate> ./configure | grep -i OPENAT
checking for openat... nofortæller dig, hvor du skal grave:
/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.Her postede jeg .
De forklarede mig, at der er noget andet i libnetwork ud over libresolv på Haiku. Tilsyneladende skal koden redigeres yderligere. Skal tænke...
find . -type f -exec sed -i -e 's|lresolv|lnetwork|g' {} ;Det evige spørgsmål: hvad sker 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 foundDet samme, kun i profil. Googlede og . Hvis du tilføjer -lssp "nogle gange" hjælper, jeg prøver:
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp"
(...)/Haiku/home/tmate> make
(...)/Haiku/home/tmate> ./tmateWow! Det begynder! Men…
[tmate] ssh.tmate.io lookup failure. Retrying in 2 seconds (non-recoverable failure in name resolution)Jeg vil prøve at fejlfinde :
/Haiku/home/tmate> strace -f ./tmate >log 2>&1"Bad port ID" er allerede som et visitkort . Måske nogen har en ide om, hvad der er galt, og hvordan man løser det? Hvis ja, vil jeg opdatere artiklen. Link til .
Portering af GUI-applikationen til Qt.
Jeg vælger en simpel 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!Virkelig simpelt. Mindre end et minut!
Emballeringsapplikationer i hpkg ved hjælp af haikuporter og haikuports.
Hvad skal jeg starte med? Der er ingen simpel dokumentation, jeg går til #haiku-kanalen på irc.freenode.net og hører:
- Team
package- en måde at oprette pakker på på lavt niveau. For det meste er PackageInfo nok for hende, som beskrevet i afsnittet "Gør det til en ordentlig .hpkg-pakke" - Jeg er nødt til at gøre noget
- Kan bruge (det går i stykker for mig, )
Det er ikke klart, hvad man skal gøre. Jeg tror, jeg har brug for en Hello World-stil begynderguide, ideelt set en video. Det ville være rart også at have en praktisk introduktion til HaikuPorter, som det gøres i GNU hello.
Jeg læser følgende:
haikuporterer et værktøj til at skabe fælles pakkeprojekter til Haiku. Den bruger HaikuPorts repository som base for alle pakker. Haikuporter-opskrifter bruges til at lave pakker.
Derudover finder jeg ud af at:
Der er ingen grund til at gemme opskrifter i HaikuPorts lager. Du kan lave et andet lager, lægge opskrifterne i det og derefter pege haikuporter på det.
Lige hvad jeg har brug for - hvis ikke jeg leder efter en måde at frigive pakken offentligt på. Men dette er et emne for et andet indlæg.
Installation af haikuporter og 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.confAt skrive en opskrift
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
}Samling af opskriften
Jeg gemmer filen under navnet QtQuickApp-1.0.recipe, hvorefter jeg starter aikuporter -S ./QuickApp-1.0.recipe. Afhængigheder kontrolleres for alle pakker i lageret , hvilket tager noget tid. Jeg tager noget kaffe.
Hvorfor i alverden skal dette tjek foretages på min lokale maskine, og ikke centralt på serveren én gang for alle?
Ifølge mr. waddlesplash:
Med sådan, at du kan omskrive en hvilken som helst fil i depotet 😉 Du kan optimere dette lidt, ved at beregne den nødvendige information, når det er nødvendigt, fordi de sidste ændringer er ret sjældne.
~/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 viser sig, at der ikke er sådan noget som en almindelig opskriftsfil, der indeholder din applikations kildekode. Du skal opbevare det i et lager i HaikuPorts-formatet.
~/QtQuickApp> mv QtQuickApp-1.0.recipe ../haikuports/app-misc/QtQuickApp/
~/QtQuickApp> ../haikuport
~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipeDette faktum gør monteringen mere besværlig. Jeg kan ikke lide det specielt, men jeg tror, det er nødvendigt, for at al open source-software til sidst vil dukke op i HaikuPorts.
Jeg får følgende:
~/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.Hvad er der galt? Efter at have læst irc gør jeg:
~/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!Et interessant spørgsmål er rejst. Hvis jeg tilføjer en kontrolsum til opskriften - vil den matche den seneste git-commit for kontinuerlig integration? (Udvikleren bekræfter: "Det vil ikke fungere. Opskrifterne er designet til at være relativt stabile.")
For sjov kan du tilføje til opskriften:
CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"Stadig ikke tilfreds:
~/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.gitHvad laver han? Dette er trods alt et git-lager, koden er der allerede direkte, der er ikke noget at pakke ud. Fra mit synspunkt burde værktøjet være smart nok til ikke at lede efter en udpakker, hvis det er over GitHub-url'en.
Måske vil uri git:// virke
SOURCE_URI="git://github.com/probonopd/QtQuickApp.git"Nu klager den sådan her:
Downloading: git://github.com/probonopd/QtQuickApp.git ...
Error: Downloading from unsafe sources is disabled in haikuports.conf!Hmm, hvorfor er alt så kompliceret, hvorfor kan du ikke "bare arbejde"? Det er trods alt ikke så ualmindeligt at bygge noget fra GitHub. Om det er værktøjer, der virker med det samme, uden behov for opsætning, eller som jeg kalder det "fussing".
Måske vil det fungere sådan her:
SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"Nix. Jeg får stadig denne mærkelige fejl og gør,
sed -i -e 's|#ALLOW_UNSAFE_SOURCES|ALLOW_UNSAFE_SOURCES|g' /boot/home/config/settings/haikuports.confJeg bevæger mig lidt længere, men hvorfor skriger den på mig (GitHub er ikke sikker!) og prøver stadig at pakke noget ud.
Ifølge :
Nå, ja, årsagen var ønsket om at kontrollere integriteten af de data, der blev modtaget til samling. En af mulighederne er at verificere kontrolsummen af arkivet, men du kan selvfølgelig hash individuelle filer, som ikke bliver implementeret, pga. det tager meget længere tid. Konsekvensen af dette er "usikkerheden" af git og andre VCS. Dette vil højst sandsynligt altid være tilfældet, da det er ret nemt og ofte hurtigere at oprette et arkiv på GitHub. Nå, i fremtiden vil fejlmeddelelsen måske ikke være så prangende... (vi fletter ikke længere sådanne opskrifter 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 2Af gammel vane går jeg og spørger gode mennesker på #haiku-kanalen på irc.freenode.net-netværket. Og hvor ville jeg være uden dem? Efter hintet indså jeg, at jeg skulle bruge:
srcGitRev="d0769f53639eaffdcd070bddfb7113c04f2a0de8"
SOURCE_URI="https://github.com/probonopd/QtQuickApp/archive/$srcGitRev.tar.gz"
SOURCE_DIR="QtQuickApp-$srcGitRev"
CHECKSUM_SHA256="db8ab861cfec0ca201e9c7b6c0c9e5e828cb4e9e69d98e3714ce0369ba9d9522"Okay, det blev klart, hvad det gør - det downloader et arkiv med kildekoden til en bestemt revision. Det er dumt, set fra mit synspunkt, og ikke lige det jeg ønskede, nemlig at downloade den seneste revision fra mastergrenen.
En af udviklerne forklarede det på denne måde:
Vi har vores eget CI, så alt, der er placeret i haikuports-depotet, vil blive pakket til alle brugere, og vi vil ikke risikere at indsamle og levere "alt i den seneste version upstream."
Forstået! Under alle omstændigheder er dette, hvad der skete:
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 gentager dette i det uendelige. Tilsyneladende er dette en fejl (er der et program? Jeg kunne ikke finde det).
С haikuporter og depot Det har ikke en "bare virker" fornemmelse over sig, men som udvikler er der nogle ting, jeg godt kan lide ved at arbejde med Haiku. For det meste ligner det Open Build Service, et sæt værktøjer til at bygge Linux-builds: ekstremt kraftfuldt, med en systematisk tilgang, men overkill til min lille "hej verden"-applikation.
Igen, ifølge hr. waddlesplash:
Faktisk er HaikuPorter ret streng som standard (plus der er en fnug-tilstand såvel som en streng tilstand for at gøre det endnu mere strengt!), men kun fordi det opretter pakker, der vil fungere, snarere end blot at oprette pakker. Det er derfor, han klager over ikke-erklærede afhængigheder, biblioteker, der ikke er importeret korrekt, forkerte versioner osv. Målet er at fange alle problemer, inklusive fremtidige, før brugeren ved om det (det er derfor, det ikke var muligt at installere avrdude, fordi afhængigheden faktisk var angivet i opskriften). Biblioteker er ikke kun individuelle pakker eller endda specifikke SO-versioner. HaikuPorter sikrer, at alt dette overholdes i selve opskrifterne for at undgå fejl under udførelsen.
I princippet er dette niveau af strenghed berettiget, når du opretter et operativsystem, men det forekommer mig unødvendigt for en "hej verden"-applikation. Jeg besluttede at prøve noget andet.
Byg applikationer i hpkg-format ved hjælp af kommandoen "package create".
Måske, Vil simple instruktioner fungere bedre for 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 menuUventet hurtig, uventet enkel, uventet effektiv. Præcis som jeg kan lide det, fantastisk!
Installation - hvad og hvor?
Flyttede filen QtQuickApp.hpkg til ~/config/packagesved hjælp af en filhåndtering, hvorefter QtQuickApp på magisk vis dukkede op ~/config/apps.
Igen, uventet hurtigt, enkelt og effektivt. Fantastisk, utroligt!
Men... (hvor ville vi være uden dem!)
Appen mangler stadig på appmenulisten og QuickLaunch. Jeg tror, jeg allerede ved, hvordan man løser det. I filhåndteringen flytter jeg QtQuickApp.hpkg fra ~/config/packages til /system/packages.
Nej, mangler stadig. Tilsyneladende gik jeg (og instruktionerne) glip af noget.
Efter at have kigget på fanen "Indhold" i HaikuDepot for nogle andre applikationer, så jeg, at der er filer som f.eks. /data/mimedb/application/x-vnd... hvad der er endnu mere bemærkelsesværdigt er /data/deskbar/menu/Applications/….
Nå, hvad skal jeg sætte der? Kom nu...
mkdir -p data/deskbar/menu/Applications/
( cd data/deskbar/menu/Applications ; ln -s ../../../../apps/QtQuickApp . )
package add QtQuickApp.hpkg apps dataJeg er helt sikker på, at dette trick vil virke, men spørgsmålene består: hvorfor er det nødvendigt, hvad er det til? Jeg tror, det ødelægger helhedsindtrykket af, at systemet er så sofistikeret.
Som forklaret af Mr. waddlesplash:
Nogle gange er der applikationer, som andre applikationer har brug for, men som ikke er i menuen. For eksempel LegacyPackageInstaller i dit skærmbillede, der behandler .pkg-arkiver i BeOS-format. Jeg vil gerne have, at brugerne installerer dem, men deres tilstedeværelse i menuen vil føre til forvirring.
Af en eller anden grund forekommer det mig, at der er en enklere løsning, f.eks Hidden=true i filer .desktop på Linux. Hvorfor ikke gøre den "skjulte" information til en ressource og egenskab for filsystemet?
Hvad der især ikke er subtilt, er navnet på (en eller anden) applikation, der viser menuen, deskbar, stift bundet undervejs.
Hr. waddlesplash forklarer dette:
"Deskbar" skal i dette tilfælde forstås som en slags generel begreb (på nogenlunde samme måde som "taskbar", der refererer til både Windows-applikationen og det generelle koncept). Nå, siden dette
deskbar, ikke "Deskbar", dette kan også forstås på lignende måde.
2 "næsten identiske" mapper med applikationer i dem
Hvorfor er der 2 mapper med applikationer, og hvorfor er min QtQuickApplication i den ene, men ikke i den anden? (Dette er jo ikke et system et, men en anden bruger, hvilket ville være forståeligt for mig personligt).
Jeg er virkelig forvirret, og jeg synes, at det her bør forenes.
kommentar af hr. waddleplash
Apps-kataloget indeholder applikationer, der ikke er nødvendige i menuen. Men situationen med menuen skal virkelig forbedres for at gøre den mere tilpasselig.
Ansøgning, ellers sker det ikke 😉
Jeg spekulerede på: er det virkelig nødvendigt at hoste applikationer i /system/apps, hvis brugerne ser dem der, er det uønsket. Måske ville det være bedre at placere dem et andet sted, hvor brugeren ikke vil støde på dem? Ligesom det er gjort i Mac OS X, hvor indholdet af pakker .app, som ikke bør være synlig for brugeren i /Applications, gemmer sig i dybet af /System/Library/…“`.
Hvad med afhængigheder?
Jeg synes, det er værd at specificere afhængighederne på en eller anden måde, ikke? Kan Qt betragtes som en obligatorisk del af Haiku-installationen som standard? Nix! Qt er ikke installeret som standard. Kan en pakkebygger automatisk registrere afhængigheder ved at kontrollere ELF-filer? Jeg fik at vide, at HaikuPorter faktisk gør dette, men package Ingen. Det er fordi det bare er en "pakkebygger", der bare opretter filer på egen hånd hpkg.
Skal Haiku gøres mere sofistikeret ved at tilføje en politik om, at en pakke ikke må have afhængigheder af pakker uden for Haiku? haikuports? (Det vil jeg gerne, fordi en sådan politik ville gøre tingene meget nemmere - systemet ville automatisk kunne løse afhængighederne af hver pakke, der downloades hvor som helst, uden at rode rundt med yderligere pakkekilder.)
Hr. waddlesplash forklarer:
Vi vil ikke begrænse udviklernes frihed så meget, for det er indlysende, at hvis CompanyX ønsker at understøtte sit eget softwaresæt med afhængigheder (og derfor et repository), vil det gøre det helt frit.
I så fald kan det være værd at anbefale, at tredjepartspakker undgår afhængigheder af alt, der ikke er inkluderet i haikuports, ved fuldstændigt at pakke alt det nødvendige med applikationen. Men jeg tror, at dette er et emne for en fremtidig artikel i denne serie. [Er forfatteren på vej mod AppImage? — ca. oversætter]
Tilføjelse af et programikon
Hvad hvis jeg vil tilføje et af de pæne indbyggede ikoner til ressourcerne i mit nyoprettede program? Det viser sig, at dette er et fantastisk emne, så det vil være grundlaget for den næste artikel.
Hvordan organiserer man kontinuerlige applikationsopbygninger?
Forestil dig et projekt som Inkscape (ja, jeg er klar over, at det endnu ikke er tilgængeligt i Haiku, men det er praktisk at vise på det). De har et kildekodelager https://gitlab.com/inkscape/inkscape.
Hver gang nogen forpligter deres ændringer til depotet, lanceres build-pipelines, hvorefter ændringerne automatisk testes, bygges, og applikationen pakkes ind i forskellige pakker, inklusive AppImage til Linux (en selvstændig applikationspakke, der kan downloades til lokal test uanset hvad der kan installeres eller ikke er installeret på systemet [Jeg vidste det! — ca. oversætter]). Det samme sker med hver anmodning om filialfletning, så du kan downloade applikationen bygget fra den kode, der er foreslået i fletningsanmodningen, før du fusionerer.
Flet anmodninger med build-statusser og muligheden for at downloade de kompilerede binære filer, hvis opbygningen er vellykket (markeret med grønt)
Bygningen kører i Docker-containere. GitLab tilbyder gratis løbere på Linux, og jeg tror, det kunne være muligt at inkludere dine egne løbere (i øvrigt kan jeg ikke se, hvordan dette ville fungere for systemer som Haiku, som jeg ved ikke har Docker eller tilsvarende, men også for FreeBSD er der ingen Docker, så dette problem er ikke unikt for Haiku).
Ideelt set kan Haiku-applikationer bygges inde i en Docker-container til Linux. I denne situation kan samlingen til Haiku indføres i eksisterende rørledninger. Findes der krydskompilere? Eller skal jeg emulere hele Haiku inde i en Docker-container ved hjælp af noget som QEMU/KVM (forudsat at det vil fungere på den måde inde i Docker)? I øvrigt bruger mange projekter lignende principper. For eksempel gør Scribus dette - det er allerede tilgængeligt til Haiku. En dag kommer dagen, hvor jeg kan sende Træk anmodninger til andre projekter for at tilføje Haiku-støtte.
En af udviklerne forklarer:
For andre projekter, der ønsker at oprette pakker selv, understøttes den almindelige CMake/CPack-metode. Andre byggesystemer kan understøttes ved at ringe direkte til pakkens byggeprogram, hvilket er fint, hvis folk er interesserede i det. Erfaringen viser: Indtil videre har der ikke været stor interesse, så haikuporter fungerede lige så bekvemt for os, men i sidste ende skulle begge metoder fungere sammen. Vi bør introducere et sæt værktøjer til cross-building-software fra Linux eller et hvilket som helst andet serveroperativsystem (Haiku er ikke designet til at køre på servere).
Jeg giver et stående bifald. Almindelige Linux-brugere bærer al denne ekstra last og ekstra bagage (sikkerhed, streng kontrol osv.), som er nødvendig for et serveroperativsystem, men ikke for et personligt. Så jeg er fuldstændig enig i, at det at være i stand til at bygge Haiku-apps på Linux er vejen at gå.
Konklusion
Portering af POSIX-applikationer til Haiku er muligt, men kan være dyrere end en typisk genopbygning. Jeg ville helt sikkert sidde fast med dette i lang tid, hvis det ikke var for hjælpen fra folk fra #haiku-kanalen på irc.freenode.net-netværket. Men selv de så ikke altid straks, hvad der var galt.
Ansøgninger skrevet i Qt er en nem undtagelse. Jeg sammensatte en simpel demo-applikation uden problemer.
Det er også ret nemt at bygge en pakke til simple applikationer, men kun for "traditionelt udgivne", dvs. have versionerede kildekodearkiver beregnet til support i haikuports. For en kontinuerlig build (byg til hver commit af ændringer) med GitHub, ser alt ud til at være ikke så enkelt. Her føles Haiku mere som en Linux-distribution end resultatet på en Mac, hvor du når du klikker på "Byg"-knappen i XCode får en pakke .app, klar til at blive indsat i et diskbillede .dmg, klargjort til download på min hjemmeside.
Kontinuerlig opbygning af applikationer baseret på et "server"-operativsystem, for eksempel Linux, vil højst sandsynligt blive muligt, hvis der er efterspørgsel fra udviklere, men i øjeblikket har Haiku-projektet andre, mere presserende opgaver.
Prøv det selv! Når alt kommer til alt, giver Haiku-projektet billeder til opstart fra DVD eller USB, genereret . For at installere skal du blot downloade billedet og skrive det til et flashdrev vha
Har du nogen spørgsmål? Vi inviterer dig til den russisktalende .
Fejloversigt:
Fra oversættelse: dette er den femte artikel i serien om Haiku.
Liste over artikler:
Kilde: www.habr.com