🥇Min femte dag med Haiku: la oss portere noen programmer

TL; DR: En nybegynner så Haiku for første gang, og prøvde å portere noen programmer fra Linux-verdenen.

Mitt første Haiku-porterte program, pakket i hpkg-formatet

Nylig Jeg oppdaget Haiku, et overraskende bra operativsystem for PC-er.
I dag skal jeg lære hvordan du porterer nye programmer til dette operativsystemet. Hovedfokuset er en beskrivelse av den første opplevelsen av å bytte til Haiku fra synspunktet til en Linux-utvikler. Jeg beklager alle dumme feil jeg har gjort underveis, siden det ikke en gang har gått en uke siden jeg lastet ned Haiku første gang.

Jeg ønsker å nå tre mål:

Porter en enkel CLI-applikasjon
Porter en applikasjon fra GUI til Qt
Pakk dem deretter i hpkg-format (siden jeg fortsatt tenker på å tilpasse AppDir og AppImage for Haiku...)

La oss komme i gang. I seksjoner dokumentasjonen и utvikling, så vel som i wiki fra HaikuPorts fant jeg riktig retning. Det er til og med en online PDF-bok BeOS: Portering av en Unix-applikasjon.
467 sider - og dette er fra 1997! Det er skummelt å se innover, men jeg håper på det beste. Utviklerens ord er oppmuntrende: "det tok lang tid fordi BeOS ikke var POSIX-kompatibelt," men Haiku "for det meste" er allerede slik.

Portering av en enkel CLI-applikasjon

Den første tanken var å portere applikasjonen avrdude, men som det viste seg, er dette allerede laget for lenge siden.

Første forsøk: ingenting å se på

Det jeg ikke kan forstå er det allerede Apper har blitt overført til Haiku i over 10 år - til tross for at selve operativsystemet ikke engang er versjon 1.0 ennå.

Andre forsøk: må skrives om

Så jeg skal bruke ptouch-770, CLI for å kontrollere Brother P-Touch 770-skriveren som jeg bruker til å skrive ut etiketter.
Jeg trykker forskjellige etiketter på den, og du har kanskje allerede sett den i forrige artikkel. Litt tidligere skrev jeg et lite GUI-innpakningsprogram i Python (siden det er i Gtk+, må det skrives om, og dette er en god grunn til å lære).

Brother P-Touch 770 etikettskriver Fungerer den med Haiku?

Haiku-pakkebehandleren vet om biblioteker og kommandoer, så hvis jeg får en "kan ikke finne libintl"-melding når jeg kjører configure - Jeg starter bare pkgman install devel:libintl og den nødvendige pakken vil bli funnet. like måte pkgman install cmd:rsync. Vel, osv.

Bortsett fra når dette ikke fungerer:

/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

Kanskje udev er for Linux-basert og eksisterer derfor ikke for Haiku. Det betyr at jeg må redigere kildekoden jeg prøver å kompilere.
Eh, du kan ikke hoppe over hodet, og jeg vet ikke engang hvor jeg skal begynne.

Tredje forsøk

Det ville vært fint å ha tmate for Haiku, så ville jeg la Haiku-utviklerne koble seg til terminaløkten min - i tilfelle noe skulle gå galt. Instruksjonene er ganske enkle:

./autogen.sh
./configure
make
make install

Ser bra ut, 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 found

I dette trinnet åpner jeg HaikuDepot og søker curses.
Noe ble funnet, som ga meg et hint for en mer kompetent spørring:

/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

Igjen dro jeg til HaikuDepot, og fant selvfølgelig devel:msgpack_c_cpp_devel. Hva er disse rare navnene?

/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

På dette trinnet innså jeg at portering av et program til Haiku krever mye mer kunnskap enn det som er nødvendig for en enkel gjenoppbygging.
Jeg snakket med de vennlige Haiku-utviklerne, det viser seg at det er en feil i msgpack, og etter noen minutter ser jeg en oppdatering i HaikuPorts. Jeg kan se med egne øyne hvordan den korrigerte pakken går hit (buildslave - virtuelle maskiner).

Bygger den korrigerte meldingspakken på buildmaster

Innimellom sender jeg en patch til oppstrøms for å legge til Haiku-støtte til msgpack.

Fem minutter senere er den oppdaterte msgpack allerede tilgjengelig 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 bra. Sa jeg det?!

Jeg går tilbake til det opprinnelige 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

Nå ser det ut til at msgpack ikke er feil. Jeg kommenterer IMAXLABEL в tty.c som følger:

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.

Vel, her er vi i gang igjen... Forresten:

/Haiku/home/tmate> ./configure | grep -i OPENAT
checking for openat... no

MR. waddleplash forteller deg 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 postet jeg config.log.

De forklarte meg at det er noe annet i libnetwork i tillegg til libresolv på Haiku. Tilsynelatende må koden redigeres ytterligere. Må tenke...

find . -type f -exec sed -i -e 's|lresolv|lnetwork|g'  {} ;

Det evige spørsmålet: hva skjer?

/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

Det samme, bare i profilen. Googlet og fant dette. Hvis du legger til -lssp "noen ganger" hjelper, jeg prøver:

/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp"
(...)/Haiku/home/tmate> make
(...)/Haiku/home/tmate> ./tmate

Wow! Det begynner! Men…

[tmate] ssh.tmate.io lookup failure. Retrying in 2 seconds (non-recoverable failure in name resolution)

Jeg skal prøve å feilsøke fil her:

/Haiku/home/tmate> strace -f ./tmate >log 2>&1

"Dårlig port-ID" er allerede som et visittkort haiku. Kanskje noen har en ide om hva som er galt og hvordan jeg kan fikse det? I så fall oppdaterer jeg artikkelen. Link til GitHub.

Portering av GUI-applikasjonen til Qt.

Jeg velger en enkel QML-applikasjon.

/> 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 enkelt. Mindre enn ett minutt!

Pakkeapplikasjoner i hpkg ved hjelp av haikuporter og haikuports.

Hva bør jeg begynne med? Det er ingen enkel dokumentasjon, jeg går til #haiku-kanalen på irc.freenode.net og hører:

Lag package - en måte å lage pakker på på lavt nivå. For det meste er PackageInfo nok for henne, som beskrevet i avsnittet "Gjør det til en skikkelig .hpkg-pakke"
Jeg må gjøre noe такое
Du kan bruke hpkg-skaper (det krasjer for meg, feilrapportering)

Det er ikke klart hva du skal gjøre. Jeg antar at jeg trenger en Hello World-stil nybegynnerguide, ideelt sett en video. Det ville vært fint å også ha en praktisk introduksjon til HaikuPorter, slik det gjøres i GNU hello.

Jeg leste følgende:

haikuporter er et verktøy for å lage felles pakkeprosjekter for Haiku. Den bruker HaikuPorts-depotet som en base for alle pakker. Haikuporter-oppskrifter brukes til å lage pakker.

I tillegg finner jeg ut at:

Det er ikke nødvendig å lagre oppskrifter i HaikuPorts lagring. Du kan lage et annet depot, legge oppskriftene i det, og deretter peke haikuporter til det.

Akkurat det jeg trenger - hvis jeg ikke leter etter en måte å offentliggjøre pakken på. Men dette er et tema for et annet innlegg.

Installere haikuporter og haikuporter

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

Å skrive en oppskrift

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
}

Setter sammen oppskriften

Jeg lagrer filen under navnet QtQuickApp-1.0.recipe, hvoretter jeg starter aikuporter -S ./QuickApp-1.0.recipe. Avhengigheter sjekkes for alle pakker i depotet haikuporter, som tar litt tid. Jeg går og henter kaffe.

Hvorfor i all verden skal denne sjekken gjøres på min lokale maskin, og ikke sentralt på serveren én gang for alle?

I følge mr. waddlesplash:

Med slik at du kan skrive om hvilken som helst fil i depotet 😉 Du kan optimere dette litt, beregne nødvendig informasjon ved behov, fordi de siste endringene som er gjort er ganske sjeldne.

~/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 viser seg at det ikke finnes en vanlig oppskriftsfil som inneholder programmets kildekode. Du må oppbevare det i et depot i HaikuPorts-formatet.

~/QtQuickApp> mv QtQuickApp-1.0.recipe ../haikuports/app-misc/QtQuickApp/
~/QtQuickApp> ../haikuport
~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe

Dette faktum gjør monteringen mer tungvint. Jeg liker det ikke spesielt, men jeg tror det er nødvendig for at all åpen kildekode-programvare skal vises 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.

Hva er galt? Etter å ha lest irc gjø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ørsmål har dukket opp. Hvis jeg legger til en sjekksum i oppskriften - vil den samsvare med den siste git-commit for kontinuerlig integrasjon? (Utvikleren bekrefter: "Det vil ikke fungere. Oppskriftene er designet for å være relativt stabile.")

For moro skyld, legg til i oppskriften:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Fortsatt ikke fornøyd:

~/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

Hva er det han gjør? Tross alt er dette et git-lager, koden er allerede der direkte, det er ingenting å pakke ut. Fra mitt synspunkt burde verktøyet være smart nok til ikke å lete etter en utpakker hvis det er over GitHub-url.

Kanskje uri git:// vil fungere

SOURCE_URI="git://github.com/probonopd/QtQuickApp.git"

Nå klager den slik:

Downloading: git://github.com/probonopd/QtQuickApp.git ...
Error: Downloading from unsafe sources is disabled in haikuports.conf!

Hmm, hvorfor er alt så komplisert, hvorfor kan du ikke "bare jobbe"? Tross alt er det ikke så uvanlig å bygge noe fra GitHub. Enten det er verktøy som fungerer med en gang, uten behov for oppsett, eller som jeg kaller det «masing».

Kanskje det vil fungere slik:

SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"

Nei. Jeg får fortsatt denne rare feilen og gjør det, som beskrevet her

sed -i -e 's|#ALLOW_UNSAFE_SOURCES|ALLOW_UNSAFE_SOURCES|g' /boot/home/config/settings/haikuports.conf

Jeg beveger meg litt lenger, men hvorfor skriker den til meg (GitHub er ikke sikker!) og prøver fortsatt å pakke ut noe.

Ifølge MR. waddleplash:

Vel, ja, grunnen var ønsket om å sjekke integriteten til dataene som ble mottatt for montering. Et av alternativene er å verifisere kontrollsummen til arkivet, men du kan selvfølgelig hash individuelle filer, som ikke vil bli implementert, fordi det tar mye lengre tid. Konsekvensen av dette er "usikkerheten" til git og andre VCS. Dette vil mest sannsynlig alltid være tilfelle, siden det er ganske enkelt og ofte raskere å lage et arkiv på GitHub. Vel, i fremtiden vil kanskje feilmeldingen ikke være så prangende... (vi slår ikke lenger sammen slike oppskrifter 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 gammel vane går jeg og spør gode folk på #haiku-kanalen på irc.freenode.net-nettverket. Og hvor ville jeg vært uten dem? Etter hintet innså jeg at jeg burde bruke:

srcGitRev="d0769f53639eaffdcd070bddfb7113c04f2a0de8"
SOURCE_URI="https://github.com/probonopd/QtQuickApp/archive/$srcGitRev.tar.gz"
SOURCE_DIR="QtQuickApp-$srcGitRev"
CHECKSUM_SHA256="db8ab861cfec0ca201e9c7b6c0c9e5e828cb4e9e69d98e3714ce0369ba9d9522"

Ok, det ble klart hva det gjør - det laster ned et arkiv med kildekoden til en viss revisjon. Det er dumt, fra mitt ståsted, og ikke akkurat det jeg ønsket, nemlig å laste ned den siste revisjonen fra mastergrenen.

En av utviklerne forklarte det slik:

Vi har vår egen CI, så alt som er plassert i haikuports-depotet vil bli pakket for alle brukere, og vi vil ikke risikere å samle inn og levere "alt i den nyeste versjonen oppstrøms."

Forstått! Dette er i alle fall hva som skjedde:

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 gjentar dette i det uendelige. Tilsynelatende er dette en feil (finnes det et program? Jeg kunne ikke finne det).

С haikuporter og depot haikuporter Det har ikke en "bare fungerer"-følelse, men som utvikler er det noen ting jeg liker ved å jobbe med Haiku. For det meste ligner den på Open Build Service, et sett med verktøy for å bygge Linux-bygg: ekstremt kraftig, med en systematisk tilnærming, men overkill for min lille "hallo verden"-applikasjon.

Igjen, ifølge mr. waddlesplash:

Faktisk er HaikuPorter ganske streng som standard (pluss det er en lo-modus så vel som en streng modus for å gjøre den enda strengere!), men bare fordi den lager pakker som vil fungere, i stedet for bare å lage pakker. Det er derfor han klager over uerklærte avhengigheter, biblioteker som ikke er importert riktig, feil versjoner osv. Målet er å fange opp alle problemer, inkludert fremtidige, før brukeren vet om det (dette er grunnen til at det ikke var mulig å installere avrdude, fordi avhengigheten faktisk var spesifisert i oppskriften). Biblioteker er ikke bare individuelle pakker eller til og med spesifikke SO-versjoner. HaikuPorter sørger for at alt dette følges i selve oppskriftene for å unngå feil under utførelse.

I prinsippet er dette nivået av strenghet rettferdiggjort når du lager et operativsystem, men det virker unødvendig for meg for en "hallo verden"-applikasjon. Jeg bestemte meg for å prøve noe annet.

Bygg applikasjoner i hpkg-format ved å bruke kommandoen "package create".

kanskje dette Vil enkle instruksjoner fungere bedre for meg?

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

Uventet raskt, uventet enkelt, uventet effektivt. Akkurat slik jeg liker det, fantastisk!

Installasjon - hva og hvor?

Flyttet filen QtQuickApp.hpkg til ~/config/packagesved hjelp av en filbehandler, hvoretter QtQuickApp på magisk vis dukket opp ~/config/apps.
Igjen, uventet raskt, enkelt og effektivt. Utrolig, utrolig!

Men... (hvor ville vi vært uten dem!)

Appen mangler fortsatt fra appmenylisten og QuickLaunch. Jeg tror jeg allerede vet hvordan jeg skal fikse det. I filbehandlingen flytter jeg QtQuickApp.hpkg fra ~/config/packages til /system/packages.

Nei, mangler fortsatt. Tilsynelatende har jeg (vel, og instruksjonene) gått glipp av noe.

Etter å ha sett på "Innhold"-fanen i HaikuDepot for noen andre applikasjoner, så jeg at det er filer som /data/mimedb/application/x-vnd... det som er enda mer bemerkelsesverdig er /data/deskbar/menu/Applications/….

Vel, hva skal jeg legge der? Kom igjen...

mkdir -p data/deskbar/menu/Applications/
( cd data/deskbar/menu/Applications ; ln -s ../../../../apps/QtQuickApp . )
package add QtQuickApp.hpkg apps data

Jeg er ganske sikker på at dette trikset vil fungere, men spørsmålene gjenstår: hvorfor er dette nødvendig, hva er det for? Jeg tror dette ødelegger helhetsinntrykket av at systemet er så sofistikert.

Som forklart av Mr. waddlesplash:

Noen ganger er det applikasjoner som andre applikasjoner trenger, men som ikke er i menyen. For eksempel LegacyPackageInstaller i skjermbildet ditt, behandler .pkg-arkiver i BeOS-format. Jeg vil at brukerne skal installere dem, men deres tilstedeværelse i menyen vil føre til forvirring.

Av en eller annen grunn ser det ut til at det finnes en enklere løsning, for eksempel Hidden=true i filer .desktop på Linux. Hvorfor ikke gjøre den "skjulte" informasjonen til en ressurs og attributt for filsystemet?

Det som er spesielt lite subtilt er navnet på (noen) applikasjon som viser menyen, deskbar, stivt bundet underveis.

MR. waddlesplash forklarer dette:

"Deskbar" i dette tilfellet skal forstås som en slags generell term (på omtrent samme måte som "oppgavelinje", som refererer til både Windows-applikasjonen og det generelle konseptet). Vel, siden dette deskbar, ikke "Deskbar", dette kan også forstås på lignende måte.

2 "nesten identiske" kataloger med applikasjoner i

Hvorfor er det 2 kataloger med applikasjoner, og hvorfor er QtQuickApplication i den ene, men ikke i den andre? (Tross alt er dette ikke ett system ett, men en andre bruker, noe som ville være forståelig for meg personlig).
Jeg er veldig forvirret, og jeg synes dette bør forenes.

kommentar av mr. waddleplash

Appkatalogen inneholder applikasjoner som ikke er nødvendige i menyen. Men situasjonen med menyen må virkelig forbedres, for å gjøre den mer tilpassbar.

Søknad, ellers skjer det ikke 😉

Jeg lurte på: er det virkelig nødvendig å være vert for applikasjoner /system/apps, hvis brukere ser dem der, er det uønsket. Kanskje det ville vært bedre å plassere dem et annet sted hvor brukeren ikke vil møte dem? Akkurat som det er gjort i Mac OS X, hvor innholdet i pakker .app, som ikke skal være synlig for brukeren i /Applications, gjemmer seg i dypet av /System/Library/…“`.

Hva med avhengigheter?

Jeg tror det er verdt å spesifisere avhengighetene på en eller annen måte, ikke sant? Kan Qt betraktes som en obligatorisk del av Haiku-installasjonen som standard? Nei! Qt er ikke installert som standard. Kan en pakkebygger automatisk oppdage avhengigheter ved å sjekke ELF-filer? Jeg ble fortalt at HaikuPorter faktisk gjør dette, men package Nei. Det er fordi det bare er en "pakkebygger" som bare lager filer på egen hånd hpkg.

Bør Haiku gjøres mer sofistikert ved å legge til en policy om at en pakke ikke skal ha avhengighet av pakker utenfor Haiku? haikuports? (Jeg vil gjerne, fordi en slik policy vil gjøre ting mye enklere - systemet vil automatisk kunne løse avhengighetene til hver pakke som lastes ned fra hvor som helst, uten å rote rundt med flere pakkekilder.)

MR. waddlesplash forklarer:

Vi vil ikke begrense utviklernes frihet så mye, fordi det er åpenbart at dersom CompanyX ønsker å støtte sitt eget sett med programvare med avhengigheter (og derfor et depot), vil det gjøre det helt fritt.

I så fall kan det være verdt å anbefale at tredjepartspakker unngår avhengigheter av alt som ikke er inkludert i haikuports ved å fullstendig pakke alt som trengs med applikasjonen. Men jeg tror dette er et tema for en fremtidig artikkel i denne serien. [Er forfatteren på vei mot AppImage? — ca. oversetter]

Legger til et programikon

Hva om jeg vil legge til et av de pene innebygde ikonene til ressursene til min nyopprettede applikasjon? Det viser seg at dette er et fantastisk emne, så det vil være grunnlaget for neste artikkel.

Hvordan organisere kontinuerlig applikasjonsbygging?

Se for deg et prosjekt som Inkscape (ja, jeg er klar over at det ennå ikke er tilgjengelig i Haiku, men det er praktisk å vise på det). De har et kildekodelager https://gitlab.com/inkscape/inkscape.
Hver gang noen forplikter endringene sine til depotet, lanseres byggepipelines, hvoretter endringene automatisk testes, bygges og applikasjonen pakkes inn i ulike pakker, inkludert AppImage for Linux (en frittstående applikasjonspakke som kan lastes ned for lokal testing uansett hva som kan installeres på systemet eller ikke [Jeg visste det! — ca. oversetter]). Det samme skjer med hver forespørsel om grensammenslåing, så du kan laste ned applikasjonen bygget fra koden som er foreslått i sammenslåingsforespørselen før du slår sammen.

Slå sammen forespørsler med byggestatuser og muligheten til å laste ned de kompilerte binærfilene hvis byggingen er vellykket (merket med grønt)

Bygget kjører i Docker-containere. GitLab tilbyr gratis løpere på Linux, og jeg tror det kan være mulig å inkludere dine egne løpere (forresten, jeg ser ikke hvordan dette ville fungere for systemer som Haiku, som jeg vet ikke har Docker eller tilsvarende, men også for FreeBSD er det ingen Docker, så dette problemet er ikke unikt for Haiku).

Ideelt sett kan Haiku-applikasjoner bygges inne i en Docker-beholder for Linux. I denne situasjonen kan monteringen for Haiku introduseres i eksisterende rørledninger. Finnes det krysskompilatorer? Eller bør jeg emulere hele Haiku inne i en Docker-beholder ved å bruke noe som QEMU/KVM (forutsatt at det vil fungere på den måten inne i Docker)? Forresten, mange prosjekter bruker lignende prinsipper. For eksempel gjør Scribus dette - det er allerede tilgjengelig for Haiku. En dag kommer dagen da jeg kan sende slik Trekk forespørsler til andre prosjekter for å legge til Haiku-støtte.

En av utviklerne forklarer:

For andre prosjekter som ønsker å lage pakker selv, støttes den vanlige CMake/CPack-metoden. Andre byggesystemer kan støttes ved å ringe pakkens byggeprogram direkte, noe som er greit hvis folk er interessert i det. Erfaringen viser: så langt har det ikke vært mye interesse, så haikuporter fungerte like praktisk for oss, men til syvende og sist burde begge metodene fungere sammen. Vi bør introdusere et sett med verktøy for kryssbyggingsprogramvare fra Linux eller et annet serveroperativsystem (Haiku er ikke laget for å kjøre på servere).

Jeg gir en stående applaus. Vanlige Linux-brukere bærer all denne ekstra lasten og ekstra bagasje (sikkerhet, streng kontroll, etc.) som er nødvendig for et serveroperativsystem, men ikke for et personlig. Så jeg er helt enig i at det å kunne bygge Haiku-apper på Linux er veien å gå.

Konklusjon

Portering av POSIX-applikasjoner til Haiku er mulig, men kan være dyrere enn en vanlig ombygging. Jeg ville definitivt sittet fast med dette i lang tid hvis det ikke var for hjelpen fra folk fra #haiku-kanalen på irc.freenode.net-nettverket. Men selv de så ikke alltid umiddelbart hva som var galt.

Søknader skrevet i Qt er et enkelt unntak. Jeg satte sammen en enkel demoapplikasjon uten problemer.

Å bygge en pakke for enkle applikasjoner er også ganske enkelt, men bare for "tradisjonelt utgitte", dvs. å ha versjonerte kildekodearkiver beregnet for støtte i haikuporter. For en kontinuerlig bygging (bygg for hver forpliktelse av endringer) med GitHub, ser alt ut til å ikke være så enkelt. Her føles Haiku mer som en Linux-distribusjon enn resultatet på en Mac, der når du klikker på "Bygg"-knappen i XCode får du en pakke .app, klar til å settes inn i et diskbilde .dmg, klargjort for nedlasting på nettstedet mitt.
Kontinuerlig bygging av applikasjoner basert på et «server»-operativsystem, for eksempel Linux, vil mest sannsynlig bli mulig dersom det er etterspørsel fra utviklere, men for øyeblikket har Haiku-prosjektet andre, mer presserende oppgaver.

Prøv det selv! Tross alt gir Haiku-prosjektet bilder for oppstart fra DVD eller USB, generert daglig. For å installere, last ned bildet og skriv det til en flash-stasjon ved hjelp av etcher

Har du noen spørsmål? Vi inviterer deg til den russisktalende telegramkanal.

Feiloversikt: Hvordan skyte deg selv i foten i C og C++. Haiku OS-oppskriftssamling

Fra forfatter oversettelse: dette er den femte artikkelen i serien om Haiku.

Liste over artikler: første Den andre tredje fjerde

Kilde: www.habr.com

Min femte dag med Haiku: la oss portere noen programmer