🥇My vyfde dag met Haiku: laat ons 'n paar programme oordra

TL; DR: 'n Nuweling het Haiku vir die eerste keer gesien en probeer om 'n paar programme van die Linux-wêreld oor te dra.

My eerste Haiku-geporteerde program, verpak in sy hpkg-formaat

Onlangs Ek het Haiku ontdek, 'n verbasend goeie bedryfstelsel vir rekenaars.
Vandag sal ek leer hoe om nuwe programme na hierdie bedryfstelsel oor te dra. Die hooffokus is 'n beskrywing van die eerste ervaring van oorskakeling na Haiku vanuit die oogpunt van 'n Linux-ontwikkelaar. Ek vra om verskoning vir enige dom foute wat ek langs die pad gemaak het, want dit is nog nie eens 'n week sedert ek die eerste keer Haiku afgelaai het nie.

Ek wil drie doelwitte bereik:

Port 'n eenvoudige CLI-toepassing
Dra 'n toepassing van GUI na Qt
Verpak hulle dan in hpkg-formaat (aangesien ek nog daaraan dink om AppDir en AppImage vir Haiku aan te pas...)

Laat ons begin. In afdelings dokumentasie и ontwikkelingsowel as wiki van HaikuPorts het ek die regte rigting gekry. Daar is selfs 'n aanlyn PDF-boek BeOS: 'n Unix-toepassing oordra.
467 bladsye - en dit is van 1997! Dit is skrikwekkend om na binne te kyk, maar ek hoop vir die beste. Die ontwikkelaar se woorde is bemoedigend: "dit het lank geneem omdat BeOS nie aan POSIX voldoen nie," maar Haiku is "vir die grootste deel" reeds so.

Oordra 'n eenvoudige CLI-toepassing

Die eerste gedagte was om die toepassing oor te dra avrdude, maar, soos dit geblyk het, is dit reeds gemaak lank gelede.

Eerste probeerslag: niks om te kyk nie

Wat ek nie kan verstaan nie, is dit reeds Toepassings word al meer as 10 jaar na Haiku oorgedra - ten spyte van die feit dat die bedryfstelsel self nog nie eens weergawe 1.0 is nie.

Tweede poging: moet herskryf

So ek sal gebruik ptouch-770, CLI vir die beheer van die Brother P-Touch 770-drukker wat ek gebruik om etikette te druk.
Ek druk verskeie etikette daarop, en jy het dit dalk al in die vorige artikel gesien. 'n Bietjie vroeër het ek 'n klein GUI-omhulprogram in Python geskryf (aangesien dit in Gtk+ is, sal dit herskryf moet word, en dit is 'n goeie rede om te leer).

Brother P-Touch 770 etiketdrukker Sal dit met Haiku werk?

Die Haiku-pakketbestuurder weet van biblioteke en opdragte, so as ek 'n "kan nie libintl vind nie"-boodskap kry wanneer ek hardloop configure - Ek begin net pkgman install devel:libintl en die vereiste pakket sal gevind word. Net so pkgman install cmd:rsync. Wel, ens.

Behalwe wanneer dit nie werk nie:

/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

Miskien is udev te Linux-gebaseerd en bestaan dit dus nie vir Haiku nie. Wat beteken dat ek die bronkode wat ek probeer saamstel moet wysig.
Eh, jy kan nie oor jou kop spring nie, en ek weet nie eers waar om te begin nie.

Derde probeerslag

Dit sal lekker wees om te hê tmate vir Haiku, dan sal ek die Haiku-ontwikkelaars toelaat om aan my terminale sessie te koppel - ingeval iets verkeerd gaan. Die instruksies is redelik eenvoudig:

./autogen.sh
./configure
make
make install

Lyk goed, so hoekom probeer dit nie op Haiku nie?

/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

In hierdie stap maak ek HaikuDepot oop en soek curses.
Iets is gevind wat my 'n wenk gegee het vir 'n meer bekwame navraag:

/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

Weer het ek na HaikuDepot gegaan, en natuurlik gevind devel:msgpack_c_cpp_devel. Wat is hierdie vreemde name?

/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

Op hierdie stap het ek besef dat die oordrag van 'n program na Haiku baie meer kennis verg as wat nodig is vir 'n eenvoudige herbou.
Ek het met die vriendelike Haiku-ontwikkelaars gepraat, dit blyk dat daar 'n fout in msgpack is, en na 'n paar minute sien ek 'n pleister in HaikuPorts. Ek kan met my eie oë sien hoe die gekorrigeerde pakket hierheen gaan (buildslave - virtuele masjiene).

Bou die gekorrigeerde boodskap op buildmaster

Tussendeur stuur ek 'n pleister stroomop toe om Haiku-ondersteuning by msgpack te voeg.

Vyf minute later is die opgedateerde boodskappak reeds in Haiku beskikbaar:

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

Onverwags goed. Het ek dit gesê?!

Ek keer terug na die oorspronklike 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 1

Nou lyk dit of msgpack nie skuldig is nie. Ek lewer kommentaar IMAXLABEL в tty.c soos volg:

tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|/*IMAXBEL|*/ISTRIP);

Gevolg:

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.

Wel, hier gaan ons weer... Terloops:

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

Mnr. waddleplash vertel jou waar om te grawe:

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

Hier het ek gepost config.log.

Hulle het aan my verduidelik dat daar iets anders in libnetwork is benewens libresolv op Haiku. Blykbaar moet die kode verder geredigeer word. Moet dink...

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

Die ewige vraag: wat gaan aan?

/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

Dieselfde ding, net in profiel. Gegoogle en dit gevind. As jy byvoeg -lssp "soms" help, ek probeer:

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

Sjoe! Dit begin! Maar …

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

Ek sal probeer ontfout lêer hier:

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

"Slegte poort ID" is reeds soos 'n besigheidskaartjie haikoe. Het iemand dalk 'n idee wat fout is en hoe om dit reg te stel? Indien wel, sal ek die artikel opdateer. Skakel na GitHub.

Dra die GUI-toepassing na Qt.

Ek kies 'n eenvoudige QML-toepassing.

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

Regtig eenvoudig. Minder as 'n minuut!

Verpak toepassings in hpkg met behulp van haikuporter en haikuports.

Waarmee moet ek begin? Daar is geen eenvoudige dokumentasie nie, ek gaan na die #haiku-kanaal op irc.freenode.net en hoor:

Span package - 'n lae-vlak manier om pakkette te skep. Vir die grootste deel is PackageInfo genoeg vir haar, soos beskryf in die afdeling "Om dit in 'n behoorlike .hpkg-pakket te maak"
Ek moet iets doen hierdie
Kan gebruik hpkg-skepper (dit crash vir my, foutrapportering)

Dit is nie duidelik wat om te doen nie. Ek dink ek benodig 'n Hello World-styl beginnersgids, ideaal 'n video. Dit sal lekker wees om ook 'n gerieflike inleiding tot HaikuPorter te hê, soos in GNU hallo gedoen word.

Ek lees die volgende:

haikuporter is 'n hulpmiddel om algemene pakketprojekte vir Haiku te skep. Dit gebruik die HaikuPorts-bewaarplek as 'n basis vir alle pakkette. Haikuporter-resepte word gebruik om pakkette te skep.

Daarbenewens vind ek uit dat:

Dit is nie nodig om resepte in HaikuPorts-berging te stoor nie. Jy kan nog 'n bewaarplek maak, die resepte daarin plaas, en dan haikuporter daarna wys.

Net wat ek nodig het - indien nie 'n manier soek om die pakket in die openbaar vry te stel nie. Maar dit is 'n onderwerp vir 'n ander pos.

Installeer 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.conf

Skryf 'n resep

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
}

Die samestelling van die resep

Ek stoor die lêer onder die naam QtQuickApp-1.0.recipe, waarna ek begin aikuporter -S ./QuickApp-1.0.recipe. Afhanklikhede word vir alle pakkette in die bewaarplek nagegaan haikuports, wat tyd neem. Ek sal koffie gaan haal.

Hoekom op aarde moet hierdie kontrole op my plaaslike masjien gedoen word, en nie een keer vir almal sentraal op die bediener nie?

Volgens mnr. waddleplash:

Met sodanig dat jy enige lêer in die bewaarplek kan herskryf 😉 Jy kan dit 'n bietjie optimeer, die nodige inligting bereken wanneer nodig, want die laaste veranderinge wat gemaak is, is redelik skaars.

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

Dit blyk dat daar nie iets soos 'n gewone reseplêer is wat jou toepassing se bronkode bevat nie. U moet dit in 'n bewaarplek in die HaikuPorts-formaat hou.

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

Hierdie feit maak die samestelling meer omslagtig. Ek hou nie juis daarvan nie, maar ek dink dit is nodig sodat alle oopbronsagteware uiteindelik in HaikuPorts sal verskyn.

Ek kry die volgende:

~/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 fout? Nadat ek irc gelees het, doen ek:

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

'n Interessante vraag het ontstaan. As ek 'n kontrolesom by die resep voeg - sal dit ooreenstem met die nuutste git-commit vir deurlopende integrasie? (Die ontwikkelaar bevestig: “Dit sal nie werk nie. Die resepte is ontwerp om relatief stabiel te wees.”)

Vir pret, voeg by die resep:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Steeds nie tevrede nie:

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

Wat doen hy? Dit is immers 'n git-bewaarplek, die kode is reeds direk daar, daar is niks om uit te pak nie. Vanuit my oogpunt behoort die instrument slim genoeg te wees om nie na 'n uitpakker te soek as dit bo die GitHub-url is nie.

Miskien sal uri git:// werk

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

Nou kla dit so:

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

Hmm, hoekom is alles so ingewikkeld, hoekom kan jy nie "net werk" nie? Dit is immers nie so ongewoon om iets van GitHub te bou nie. Of dit nou gereedskap is wat dadelik werk, sonder die behoefte aan opstelling, of soos ek dit noem "fussing".

Miskien sal dit so werk:

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

Nope. Ek kry steeds hierdie vreemde fout en doen, soos hier beskryf

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

Ek beweeg 'n bietjie verder, maar hoekom skree dit vir my (GitHub is nie veilig nie!) en probeer steeds om iets uit te pak.

Volgens Mnr. waddleplash:

Wel, ja, die rede was die begeerte om die integriteit van die data wat vir samestelling ontvang is, na te gaan. Een van die opsies is om die kontrolesom van die argief te verifieer, maar jy kan natuurlik individuele lêers hash, wat nie geïmplementeer sal word nie, want dit neem baie langer. Die gevolg hiervan is die "onsekerheid" van git en ander VCS. Dit sal heel waarskynlik altyd die geval wees, aangesien die skep van 'n argief op GitHub redelik maklik en dikwels vinniger is. Wel, in die toekoms sal die foutboodskap dalk nie so spoggerig wees nie... (ons smelt nie meer sulke resepte in HaikuPorts saam nie).

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

Uit ou gewoonte gaan vra ek goeie mense op die #haiku-kanaal op die irc.freenode.net-netwerk. En waar sou ek wees sonder hulle? Na die wenk het ek besef dat ek moet gebruik:

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

Goed, dit het duidelik geword wat dit doen - dit laai 'n argief af met die bronkode van 'n sekere hersiening. Dit is dom, uit my oogpunt, en nie presies wat ek wou hê nie, naamlik om die nuutste weergawe van die meestertak af te laai.

Een van die ontwikkelaars het dit so verduidelik:

Ons het ons eie CI, so alles wat in die haikuports-bewaarplek geplaas word, sal vir alle gebruikers verpak word, en ons wil nie die risiko loop om "alles in die nuutste weergawe stroomop" te versamel en af te lewer nie.

Verstaan! Dit is in elk geval wat gebeur het:

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
(...)

Dit herhaal hierdie ad infinitum. Dit is blykbaar 'n fout (is daar 'n toepassing? Ek kon dit nie vind nie).

С haikuporter en bewaarplek haikuports Dit het nie 'n "werk net"-gevoel nie, maar as 'n ontwikkelaar is daar 'n paar dinge waarvan ek hou om met Haiku te werk. Vir die grootste deel is dit soortgelyk aan die Open Build Service, 'n stel gereedskap vir die bou van Linux-geboue: uiters kragtig, met 'n sistematiese benadering, maar oordrewe vir my klein "hallo wêreld"-toepassing.

Weereens, volgens mnr. waddleplash:

Inderdaad, HaikuPorter is by verstek redelik streng (plus daar is 'n pluismodus sowel as 'n streng modus om dit nog strenger te maak!), maar net omdat dit pakkette skep wat sal werk, eerder as om net pakkette te skep. Daarom kla hy oor onverklaarde afhanklikhede, biblioteke wat nie behoorlik ingevoer is nie, verkeerde weergawes, ens. Die doel is om enige en alle probleme, insluitend toekomstiges, op te vang voordat die gebruiker daarvan weet (dit is hoekom dit nie moontlik was om avrdude te installeer nie, want die afhanklikheid is eintlik in die resep gespesifiseer). Biblioteke is nie net individuele pakkette of selfs spesifieke SO-weergawes nie. HaikuPorter verseker dat dit alles in die resepte self waargeneem word om foute tydens uitvoering te vermy.

In beginsel is hierdie vlak van strengheid geregverdig wanneer 'n bedryfstelsel geskep word, maar dit lyk vir my onnodig vir 'n "hallo wêreld"-toepassing. Ek het besluit om iets anders te probeer.

Bou toepassings in hpkg-formaat deur die "package create"-opdrag te gebruik

Kan wees, hierdie Sal eenvoudige instruksies beter vir my werk?

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

Onverwags vinnig, onverwags eenvoudig, onverwags effektief. Presies hoe ek daarvan hou, ongelooflik!

Installasie - wat en waar?

Het die QtQuickApp.hpkg-lêer geskuif na ~/config/packagesmet behulp van 'n lêerbestuurder, waarna QtQuickApp magies in verskyn het ~/config/apps.
Weereens, onverwags vinnig, eenvoudig en effektief. Wonderlik, ongelooflik!

Maar ... (waar sou ons sonder hulle wees!)

Die toepassing ontbreek steeds in die toepassingskieslyslys en QuickLaunch. Ek dink ek weet reeds hoe om dit reg te maak. In die lêerbestuurder skuif ek QtQuickApp.hpkg van ~/config/packages na /system/packages.

Nee, nog steeds vermis. Blykbaar het ek (wel, en die instruksies) iets gemis.

Nadat ek na die "Inhoud"-oortjie in HaikuDepot vir 'n paar ander toepassings gekyk het, het ek gesien dat daar lêers is soos /data/mimedb/application/x-vnd... wat nog meer merkwaardig is, is /data/deskbar/menu/Applications/….

Wel, wat moet ek daar sit? Kom nou...

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

Ek is seker dat hierdie truuk sal werk, maar die vrae bly: hoekom is dit nodig, waarvoor is dit? Ek dink dit vernietig die algehele indruk dat die stelsel so gesofistikeerd is.

Soos verduidelik deur mnr. waddleplash:

Soms is daar toepassings wat ander toepassings benodig, maar nie in die spyskaart is nie. Byvoorbeeld, LegacyPackageInstaller in jou skermkiekie, verwerking van .pkg-argiewe in BeOS-formaat. Ek wil graag hê dat gebruikers dit moet installeer, maar hul teenwoordigheid in die spyskaart sal tot verwarring lei.

Om een of ander rede lyk dit vir my of daar byvoorbeeld 'n eenvoudiger oplossing is Hidden=true in lêers .desktop op Linux. Hoekom nie die "versteekte" inligting 'n hulpbron en kenmerk van die lêerstelsel maak nie?

Wat veral nie subtiel is nie, is die naam van (een of ander) toepassing wat die spyskaart wys, deskbar, stewig vasgebind langs die pad.

Mnr. waddlesplash verduidelik dit:

"Deskbar" in hierdie geval moet verstaan word as 'n soort algemene term (op dieselfde manier as "taakbalk", wat verwys na beide die Windows-toepassing en die algemene konsep). Wel, sedert hierdie deskbar, nie "Deskbar" nie, dit kan ook op 'n soortgelyke manier verstaan word.

2 "amper identiese" dopgehou met toepassings daarin

Hoekom is daar 2 dopgehou met toepassings, en ook hoekom is my QtQuickApplication in die een, maar nie in die ander nie? (Dit is immers nie een stelsel een nie, maar 'n tweede gebruiker een, wat vir my persoonlik verstaanbaar sal wees).
Ek is regtig deurmekaar en ek dink dit moet verenig word.

kommentaar deur mnr. waddleplash

Die toepassingskatalogus bevat toepassings wat nie in die kieslys benodig word nie. Maar die situasie met die spyskaart moet regtig verbeter word, om dit meer aanpasbaar te maak.

Aansoek, of dit sal nie gebeur nie 😉

Ek het gewonder: is dit regtig nodig om toepassings in te huisves /system/apps, as gebruikers hulle daar sien, is dit ongewens. Miskien sal dit beter wees om hulle op 'n ander plek te plaas waar die gebruiker hulle nie sal teëkom nie? Net soos dit gedoen word in Mac OS X, waar die inhoud van pakkette .app, wat nie sigbaar moet wees vir die gebruiker in /Applications, wegkruip in die dieptes van /System/Library/…“`.

Wat van afhanklikhede?

Ek dink dit is die moeite werd om die afhanklikhede op een of ander manier te spesifiseer, reg? Kan Qt by verstek as 'n verpligte deel van die Haiku-installasie beskou word? Nope! Qt is nie by verstek geïnstalleer nie. Kan 'n pakketbouer outomaties afhanklikhede opspoor deur ELF-lêers na te gaan? Ek is meegedeel dat HaikuPorter dit eintlik doen, maar package Geen. Dit is omdat dit net 'n "pakketbouer" is wat net lêers op sy eie skep hpkg.

Moet Haiku meer gesofistikeerd gemaak word deur 'n beleid by te voeg dat 'n pakket nie afhanklikhede van pakkette buite Haiku moet hê nie? haikuports? (Ek wil graag, want so 'n beleid sal dinge baie makliker maak - die stelsel sal outomaties die afhanklikhede van elke pakket wat van enige plek afgelaai word, kan oplos, sonder om met bykomende pakketbronne rond te mors.)

Mnr. waddlesplash verduidelik:

Ons wil nie die vryheid van ontwikkelaars so beperk nie, want dit is duidelik dat as CompanyX sy eie stel sagteware met afhanklikhede (en dus 'n bewaarplek) wil ondersteun, dit dit heeltemal vrylik sal doen.

In daardie geval kan dit die moeite werd wees om aan te beveel dat derdeparty-pakkette afhanklikhede vermy van enigiets wat nie by haikuports ingesluit is nie deur alles wat nodig is met die toepassing volledig te verpak. Maar ek dink dit is 'n onderwerp vir 'n toekomstige artikel in hierdie reeks. [Is die skrywer op pad na AppImage? — ongeveer. vertaler]

Voeg 'n toepassingsikoon by

Wat as ek een van die netjiese ingeboude ikone by die hulpbronne van my nuutgeskepte toepassing wil voeg? Dit blyk dat dit 'n wonderlike onderwerp is, so dit sal die basis vir die volgende artikel wees.

Hoe om deurlopende toepassingsbou te organiseer?

Stel jou 'n projek soos Inkscape voor (ja, ek is bewus daarvan dat dit nog nie in Haiku beskikbaar is nie, maar dit is gerieflik om daarop te vertoon). Hulle het 'n bronkode-bewaarplek https://gitlab.com/inkscape/inkscape.
Elke keer as iemand hul veranderinge aan die bewaarplek verbind, word boupyplyne geloods, waarna die veranderinge outomaties getoets, gebou word en die toepassing in verskeie pakkette verpak word, insluitend AppImage vir Linux ('n selfstandige toepassingspakket wat afgelaai kan word vir plaaslike toetsing, ongeag wat op die stelsel geïnstalleer mag word of nie [Ek het dit geweet! — ongeveer. vertaler]). Dieselfde ding gebeur met elke taksamesmeltingversoek, so jy kan die toepassing aflaai wat gebou is uit die kode wat in die samesmeltingsversoek voorgestel word voordat jy saamsmelt.

Voeg versoeke saam met boustatusse en die vermoë om die saamgestelde binaries af te laai as die bou suksesvol is (in groen gemerk)

Die bouwerk loop in Docker-houers. GitLab bied gratis hardlopers op Linux, en ek dink dit kan moontlik wees om jou eie hardlopers in te sluit (terloops, ek sien nie hoe dit sal werk vir stelsels soos Haiku, wat ek weet nie Docker of ekwivalent het nie, maar ook vir FreeBSD is daar geen Docker nie, so hierdie probleem is nie uniek aan Haiku nie).

Ideaal gesproke kan Haiku-toepassings binne 'n Docker-houer vir Linux gebou word. In hierdie situasie kan die samestelling vir Haiku in bestaande pypleidings ingebring word. Is daar kruissamestellers? Of moet ek die hele Haiku binne 'n Docker-houer naboots deur iets soos QEMU/KVM te gebruik (met die veronderstelling dat dit so binne Docker sal werk)? Terloops, baie projekte gebruik soortgelyke beginsels. Scribus doen dit byvoorbeeld – dit is reeds vir Haiku beskikbaar. Eendag kom die dag dat ek kan stuur sodanige Trek versoeke na ander projekte om Haiku-ondersteuning by te voeg.

Een van die ontwikkelaars verduidelik:

Vir ander projekte wat self pakkette wil skep, word die gewone CMake/CPack-metode ondersteun. Ander boustelsels kan ondersteun word deur die pakket se bouprogram direk te skakel, wat goed is as mense daarin belangstel. Ervaring wys: tot dusver was daar nie veel belangstelling nie, so haikuporter het so gerieflik vir ons gewerk, maar uiteindelik moet albei metodes saamwerk. Ons moet 'n stel gereedskap bekendstel vir kruisbou sagteware van Linux of enige ander bediener bedryfstelsel (Haiku is nie ontwerp om op bedieners te loop nie).

Ek gee 'n staande ovasie. Gereelde Linux-gebruikers dra al hierdie bykomende vrag en bykomende bagasie (sekuriteit, streng beheer, ens.) wat nodig is vir 'n bedienerbedryfstelsel, maar nie vir 'n persoonlike een nie. So ek stem heeltemal saam dat om Haiku-toepassings op Linux te kan bou, die pad is om te gaan.

Gevolgtrekking

Die oordrag van POSIX-toepassings na Haiku is moontlik, maar kan duurder wees as 'n tipiese herbou. Ek sou beslis lank hiermee vasgehaak het as dit nie was vir die hulp van mense van die #haiku-kanaal op die irc.freenode.net-netwerk nie. Maar selfs hulle het nie altyd dadelik gesien wat fout is nie.

Aansoeke wat in Qt geskryf is, is 'n maklike uitsondering. Ek het sonder enige probleme 'n eenvoudige demo-toepassing saamgestel.

Om 'n pakket vir eenvoudige toepassings te bou is ook redelik maklik, maar slegs vir "tradisioneel vrygestelde"s, d.w.s. met weergawes van bronkode-argiewe wat bedoel is vir ondersteuning in haikuports. Vir 'n deurlopende bou (bou vir elke commit van veranderinge) met GitHub, blyk alles nie so eenvoudig te wees nie. Hier voel Haiku meer soos 'n Linux-verspreiding as die resultaat op 'n Mac, waar wanneer jy op die "Build"-knoppie in XCode klik, kry jy 'n pakket .app, gereed om in 'n skyfbeeld ingevoeg te word .dmg, voorberei vir aflaai op my webwerf.
Deurlopende bou van toepassings gebaseer op 'n "bediener"-bedryfstelsel, byvoorbeeld Linux, sal heel waarskynlik moontlik word as daar aanvraag van ontwikkelaars is, maar op die oomblik het die Haiku-projek ander, meer dringende take.

Probeer dit self! Die Haiku-projek verskaf immers beelde vir selflaai vanaf DVD of USB, gegenereer daaglikse. Om te installeer, laai net die prent af en brand dit op 'n USB-flash drive met behulp van etser

Het jy vrae? Ons nooi jou uit na die Russiessprekende telegramkanaal.

Foutoorsig: Hoe om jouself in die voet te skiet in C en C++. Haiku OS-resepteversameling

Van die skrywer vertaling: dit is die vyfde artikel in die reeks oor Haiku.

Lys van artikels: Eerste Die tweede Третья Vierde

Bron: will.com

My vyfde dag met Haiku: laat ons 'n paar programme oordra