🥇Můj pátý den s Haiku: pojďme portovat nějaké programy

TL, DR: Nováček viděl Haiku poprvé, když se snažil přenést některé programy ze světa Linuxu.

Můj první portovaný program Haiku, zabalený ve formátu hpkg

Nedávno Objevil jsem Haiku, překvapivě dobrý operační systém pro PC.
Dnes se naučím portovat nové programy do tohoto operačního systému. Hlavní náplní je popis prvních zkušeností s přechodem na Haiku z pohledu linuxového vývojáře. Omlouvám se za všechny hloupé chyby, které jsem cestou udělal, protože to není ani týden, co jsem si Haiku poprvé stáhl.

Chci dosáhnout tří cílů:

Port jednoduché CLI aplikace
Port aplikace z GUI do Qt
Pak je zabalte do formátu hpkg (protože stále přemýšlím o přizpůsobení AppDir a AppImage pro Haiku...)

Začněme. V sekcích dokumentaci и vývoj, stejně jako v wiki z HaikuPorts jsem našel správný směr. Existuje dokonce online kniha PDF BeOS: Portování unixové aplikace.
467 stran - a to je z roku 1997! Pohled dovnitř je děsivý, ale doufám v to nejlepší. Slova vývojáře jsou povzbudivá: „trvalo to dlouho, protože BeOS nebyl kompatibilní s POSIX“, ale Haiku „z velké části“ už je.

Portování jednoduché CLI aplikace

První myšlenka byla přenést aplikaci avrdudu, ale jak se ukázalo, to už je udělali před dávnými časy.

První pokus: není co sledovat

Co nedokážu pochopit, je to už Aplikace byly do Haiku portovány již více než 10 let - přesto, že samotný OS ještě není ani verze 1.0.

Druhý pokus: potřeba přepsat

Takže použiji ptouch-770, CLI pro ovládání tiskárny Brother P-Touch 770, kterou používám k tisku štítků.
Tisknu na něj různé štítky a možná jste ho už viděli v předchozím článku. O něco dříve jsem v Pythonu napsal malý GUI wrapper program (protože je v Gtk+, bude se muset přepsat, a to je dobrý důvod se učit).

Tiskárna štítků Brother P-Touch 770. Bude fungovat s Haiku?

Správce balíčků Haiku ví o knihovnách a příkazech, takže pokud se mi při spuštění zobrazí zpráva „nelze najít libintl“ configure - Právě spouštím pkgman install devel:libintl a požadovaný balíček bude nalezen. Rovněž pkgman install cmd:rsync. No atd.

Kromě případů, kdy to nefunguje:

/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

Možná je udev příliš založený na Linuxu, a proto pro Haiku neexistuje. Což znamená, že musím upravit zdrojový kód, který se snažím zkompilovat.
Eh, nemůžeš skákat přes hlavu a já ani nevím, kde začít.

Třetí pokus

Bylo by hezké mít tmate pro Haiku bych pak vývojářům Haiku umožnil připojit se k mé terminálové relaci - pro případ, že by se něco pokazilo. Návod je celkem jednoduchý:

./autogen.sh
./configure
make
make install

Vypadá to dobře, tak proč to nezkusit na 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

V tomto kroku otevřu HaikuDepot a hledám curses.
Bylo nalezeno něco, co mi dalo tip na kompetentnější dotaz:

/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

Znovu jsem šel do HaikuDepot a samozřejmě našel devel:msgpack_c_cpp_devel. Co jsou to za podivná jména?

/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

V tomto kroku jsem si uvědomil, že portování programu na Haiku vyžaduje mnohem více znalostí, než je potřeba pro jednoduchou přestavbu.
Mluvil jsem s přátelskými vývojáři Haiku, ukázalo se, že v msgpacku je chyba a po několika minutách vidím opravu v HaikuPorts. Na vlastní oči vidím, jak opravený balíček jít sem (buildslave - virtuální stroje).

Sestavení opraveného msgpacku na buildmasteru

Mezitím posílám patch do upstreamu přidat podporu Haiku do msgpack.

O pět minut později je již aktualizovaný msgpack dostupný v 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.

Nečekaně dobré. Řekl jsem to?!

Vrátím se k původnímu problému:

/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

Nyní to vypadá, že msgpack není na vině. komentuji IMAXLABEL в tty.c následovně:

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

Výsledek:

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.

Tak a zase je to tady... Mimochodem:

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

pan. waddlesplash řekne, kde kopat:

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

Zde jsem zveřejnil config.log.

Vysvětlili mi, že kromě libresolvu na Haiku je v libnetwork ještě něco jiného. Kód je zřejmě potřeba dále upravovat. Je potřeba přemýšlet…

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

Věčná otázka: co se děje?

/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

To samé, jen v profilu. Google a našel toto. Pokud přidáte -lssp "někdy" pomáhá, zkouším:

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

Páni! Už to začíná! Ale…

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

Zkusím odladit soubor zde:

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

„Špatné ID portu“ je již jako vizitka haiku. Možná má někdo nápad, co je špatně a jak to opravit? Pokud ano, aktualizuji článek. Odkaz na GitHub.

Portování GUI aplikace na Qt.

Volím jednoduchou QML aplikaci.

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

Opravdu jednoduché. Méně než minutu!

Balení aplikací do hpkg pomocí haikuporter a haikuports.

Čím bych měl začít? Neexistuje žádná jednoduchá dokumentace, jdu na kanál #haiku na irc.freenode.net a slyším:

Tým package - nízkoúrovňový způsob vytváření balíčků. Z velké části jí stačí PackageInfo, jak je popsáno v sekci "Udělat z toho pořádný .hpkg balíček"
Musím něco udělat je
Může použít hpkg-creator (spadne mi to, hlášení chyb)

Není jasné, co dělat. Asi potřebuji příručku pro začátečníky ve stylu Hello World, ideálně video. Bylo by hezké mít také pohodlný úvod do HaikuPorter, jak se to dělá v GNU hello.

čtu následující:

haikuporter je nástroj pro vytváření společných balíkových projektů pro Haiku. Jako základ pro všechny balíčky používá úložiště HaikuPorts. Recepty Haikuporter se používají k vytváření balíčků.

Navíc zjišťuji, že:

Není potřeba ukládat recepty do úložiště HaikuPorts. Můžete vytvořit další úložiště, vložit do něj recepty a pak na něj nasměrovat haikuporter.

Přesně to, co potřebuji - pokud nehledám způsob, jak balíček veřejně uvolnit. Ale to je téma na jiný příspěvek.

Instalace haikuporter a 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

Psaní receptu

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
}

Sestavení receptury

Soubor ukládám pod jménem QtQuickApp-1.0.recipe, po kterém spustím aikuporter -S ./QuickApp-1.0.recipe. Závislosti jsou kontrolovány pro všechny balíčky v úložišti haikuporty, což nějakou dobu trvá. Jdu si dát kávu.

Proč by se proboha měla tato kontrola provádět na mém místním počítači a ne centrálně na serveru jednou pro všechny?

Podle pana waddlesplash:

S takovým, že můžete přepsat jakýkoli soubor v úložišti 😉 Můžete to trochu optimalizovat a v případě potřeby vypočítat potřebné informace, protože poslední změny jsou poměrně vzácné.

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

Ukázalo se, že neexistuje nic takového jako běžný soubor receptů, který by obsahoval zdrojový kód vaší aplikace. Musíte jej uchovávat v úložišti ve formátu HaikuPorts.

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

Tato skutečnost činí montáž obtížnější. Nijak zvlášť se mi to nelíbí, ale myslím si, že je to nutné, aby se nakonec veškerý open source software objevil v HaikuPorts.

Dostávám následující:

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

Co je špatně? Po přečtení irc udělám:

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

Vyvstala zajímavá otázka. Pokud do receptu přidám kontrolní součet – bude odpovídat nejnovějšímu odevzdání git pro nepřetržitou integraci? (Vývojář potvrzuje: "Nebude to fungovat. Recepty jsou navrženy tak, aby byly relativně stabilní.")

Pro zajímavost do receptu přidejte:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Stále nespokojen:

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

Co dělá? Přeci jen se jedná o git repozitář, kód tam už přímo je, není co rozbalovat. Z mého pohledu by měl být nástroj dostatečně chytrý, aby nehledal unpacker, pokud je nad url GitHubu.

Možná bude fungovat uri git://

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

Nyní si stěžuje takto:

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

Hmm, proč je všechno tak složité, proč nemůžete „jen pracovat“? Ostatně není až tak neobvyklé postavit něco z GitHubu. Ať už jde o nástroje, které fungují hned, bez nutnosti nastavování, nebo jak tomu říkám „fušování“.

Možná to bude fungovat takto:

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

Ani náhodou. Stále dostávám tuto podivnou chybu a dělám, jak je zde popsáno

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

Posouvám se o kousek dál, ale proč to na mě křičí (GitHub není zabezpečený!) a pořád se snaží něco vybalit.

Podle pan. waddlesplash:

No, ano, důvodem byla touha zkontrolovat integritu dat přijatých k sestavení. Jednou z možností je ověření kontrolního součtu archivu, ale můžete samozřejmě jednotlivé soubory hašovat, což nebude implementováno, protože trvá to mnohem déle. Důsledkem toho je „nebezpečnost“ git a dalších VCS. S největší pravděpodobností to tak bude vždy, protože vytvoření archivu na GitHubu je poměrně snadné a často rychlejší. No, do budoucna snad ta chybová hláška nebude tak honosná... (v HaikuPorts už takové recepty neslučujeme).

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

Ze starého zvyku se chodím ptát dobrých lidí na kanál #haiku na síti irc.freenode.net. A kde bych bez nich byl? Po nápovědě jsem si uvědomil, že bych měl použít:

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

Dobře, bylo jasné, co to dělá - stahuje archiv se zdrojovým kódem určité revize. Z mého pohledu je to hloupé a ne přesně to, co jsem chtěl, totiž stáhnout nejnovější revizi z hlavní větve.

Jeden z vývojářů to vysvětlil takto:

Máme vlastní CI, takže vše, co je umístěno v úložišti haikuports, bude zabaleno pro všechny uživatele a nechceme riskovat shromažďování a dodávání „všeho v nejnovější verzi upstream“.

Rozumím! V každém případě se stalo toto:

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

Opakuje to do nekonečna. Zřejmě se jedná o chybu (existuje nějaká aplikace? Nenašel jsem ji).

С haikuporter a úložiště haikuporty Nemá to pocit „jen funguje“, ale jako vývojář se mi na práci s Haiku líbí některé věci. Z velké části se podobá službě Open Build Service, sadě nástrojů pro vytváření sestavení Linuxu: extrémně výkonné, se systematickým přístupem, ale přehnané pro moji malou aplikaci „ahoj světe“.

Opět podle Mr. waddlesplash:

Ve skutečnosti je HaikuPorter ve výchozím nastavení poměrně přísný (navíc existuje režim lint a také přísný režim, aby byl ještě přísnější!), ale pouze proto, že vytváří balíčky, které budou fungovat, spíše než jen balíčky. Proto si stěžuje na nedeklarované závislosti, špatně naimportované knihovny, nesprávné verze atp. Cílem je zachytit všechny problémy, včetně budoucích, dříve, než se o nich uživatel dozví (proto nebylo možné avrdude nainstalovat, protože závislost byla ve skutečnosti uvedena v receptu). Knihovny nejsou jen jednotlivé balíčky nebo dokonce konkrétní verze SO. HaikuPorter zajišťuje, že toto vše je dodrženo v samotných recepturách, aby se předešlo chybám při provádění.

V zásadě je tato míra přísnosti opodstatněná při vytváření operačního systému, ale pro aplikaci „ahoj světe“ se mi zdá zbytečná. Rozhodl jsem se zkusit něco jiného.

Vytváření aplikací ve formátu hpkg pomocí příkazu „package create“.

Možná tohle Budou pro mě jednoduché pokyny fungovat lépe?

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

Nečekaně rychlé, nečekaně jednoduché, nečekaně efektní. Přesně jak se mi to líbí, úžasné!

Instalace - co a kde?

Přesunul soubor QtQuickApp.hpkg do ~/config/packagespomocí správce souborů, po kterém se jako kouzlem objevil QtQuickApp ~/config/apps.
Opět nečekaně rychlé, jednoduché a efektivní. Úžasné, neuvěřitelné!

Ale... (kde bychom bez nich byli!)

Aplikace stále chybí v seznamu nabídek aplikací a QuickLaunch. Myslím, že už vím, jak to opravit. Ve správci souborů přesunu QtQuickApp.hpkg z ~/config/packages do /system/packages.

Ne, stále chybí. Zřejmě mi (no a návod) něco uniklo.

Když jsem se podíval na kartu "Obsah" v HaikuDepot pro některé další aplikace, viděl jsem, že existují soubory jako /data/mimedb/application/x-vnd... co je ještě pozoruhodnější /data/deskbar/menu/Applications/….

No a co tam mám dát? no tak...

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

Jsem si docela jistý, že tento trik bude fungovat, ale zůstávají otázky: proč je to nutné, k čemu to je? Myslím, že to kazí celkový dojem, že systém je tak propracovaný.

Jak vysvětlil Mr. waddlesplash:

Někdy existují aplikace, které jiné aplikace potřebují, ale nejsou v nabídce. Například LegacyPackageInstaller na vašem snímku obrazovky, zpracovávající archivy .pkg ve formátu BeOS. Chtěl bych, aby si je uživatelé nainstalovali, ale jejich přítomnost v nabídce povede ke zmatku.

Z nějakého důvodu se mi zdá, že existuje například jednodušší řešení Hidden=true v souborech .desktop na Linuxu. Proč neudělat ze „skrytých“ informací zdroj a atribut systému souborů?

Co není obzvláště nenápadné, je název (nějaké) aplikace, která zobrazuje menu, deskbar, pevně svázaný po cestě.

pan. waddlesplash vysvětluje toto:

„Deskbar“ je v tomto případě třeba chápat jako jakýsi obecný termín (v podstatě stejně jako „hlavní panel“, který odkazuje jak na aplikaci Windows, tak na obecný koncept). No, od tohohle deskbar, nikoli „Deskbar“, to lze také chápat podobně.

2 "téměř identické" adresáře s aplikacemi v nich

Proč jsou tam 2 adresáře s aplikacemi a proč je moje QtQuickApplication v jednom, ale ne v druhém? (Přece jen se nejedná o jeden systémový, ale o druhý uživatelský, což by bylo pro mě osobně pochopitelné).
Jsem opravdu zmatený a myslím, že by se to mělo sjednotit.

komentář pana waddlesplash

Katalog aplikací obsahuje aplikace, které v nabídce nejsou potřeba. Situaci s nabídkou je ale opravdu potřeba zlepšit, aby byla lépe přizpůsobitelná.

Aplikace, nebo se to nestane 😉

Přemýšlel jsem: je opravdu nutné hostovat aplikace v /system/apps, pokud je tam uživatelé uvidí, je to nežádoucí. Možná by bylo lepší umístit je na jiné místo, kde se s nimi uživatel nesetká? Stejně jako se to dělá v Mac OS X, kde je obsah balíčků .app, který by neměl být viditelný pro uživatele v /Applications, ukrývající se v hlubinách /System/Library/…“`.

A co závislosti?

Myslím, že stojí za to ty závislosti nějak specifikovat, ne? Lze Qt ve výchozím nastavení považovat za povinnou součást instalace Haiku? Ani náhodou! Qt není ve výchozím nastavení nainstalováno. Může tvůrce balíčků automaticky detekovat závislosti kontrolou souborů ELF? Bylo mi řečeno, že HaikuPorter to skutečně dělá, ale package Ne. Je to proto, že je to jen "tvůrce balíčků", který pouze vytváří soubory sám hpkg.

Mělo by být Haiku sofistikovanější přidáním zásady, že balíček by neměl být závislý na balíčcích mimo Haiku? haikuports? (Rád bych, protože taková politika by věci hodně usnadnila – systém by byl schopen automaticky vyřešit závislosti každého balíčku staženého odkudkoli, aniž by se musel potýkat s dalšími zdroji balíčků.)

pan. waddlesplash vysvětluje:

Neradi bychom tolik omezovali svobodu vývojářů, protože je zřejmé, že pokud chce CompanyX podporovat vlastní sadu softwaru se závislostmi (a tedy úložištěm), bude tak činit zcela svobodně.

V takovém případě by možná stálo za to doporučit, aby se balíčky třetích stran vyhnuly závislostem na čemkoli, co není zahrnuto v haikuports, tím, že kompletně zabalí vše potřebné do aplikace. Ale myslím, že toto je téma pro budoucí článek z této série. [Směřuje autor k AppImage? - Cca. překladatel]

Přidání ikony aplikace

Co když chci přidat jednu z elegantních vestavěných ikon do prostředků mé nově vytvořené aplikace? Ukazuje se, že je to úžasné téma, takže to bude základ pro další článek.

Jak organizovat průběžné sestavení aplikací?

Představte si projekt jako Inkscape (ano, jsem si vědom toho, že ještě není dostupný v Haiku, ale je vhodné jej na něm zobrazit). Mají úložiště zdrojového kódu https://gitlab.com/inkscape/inkscape.
Pokaždé, když někdo odešle své změny do úložiště, spustí se kanály sestavení, poté se změny automaticky otestují, sestaví a aplikace se zabalí do různých balíčků, včetně AppImage pro Linux (samostatný balíček aplikací, který lze stáhnout pro místní testování bez ohledu na co může nebo nemusí být nainstalováno v systému [Věděl jsem to! - Cca. překladatel]). Totéž se děje s každou žádostí o sloučení větve, takže si před sloučením můžete stáhnout aplikaci vytvořenou z kódu navrženého v žádosti o sloučení.

Sloučit požadavky se stavy sestavení a možností stáhnout zkompilované binární soubory, pokud je sestavení úspěšné (označeno zeleně)

Sestavení běží v kontejnerech Docker. GitLab nabízí bezplatné běžce na Linuxu a myslím, že by mohlo být možné zahrnout vaše vlastní běžce (mimochodem, nechápu, jak by to fungovalo pro systémy jako Haiku, o kterých vím, že nemají Docker ani ekvivalent, ale také pro FreeBSD neexistuje Docker, takže tento problém není jedinečný pro Haiku).

V ideálním případě lze aplikace Haiku zabudovat do kontejneru Docker pro Linux. V této situaci může být sestava pro Haiku zavedena do stávajících potrubí. Existují křížové kompilátory? Nebo bych měl emulovat všechny Haiku v kontejneru Docker pomocí něčeho jako QEMU/KVM (za předpokladu, že to bude fungovat v Dockeru)? Mimochodem, mnoho projektů používá podobné principy. Například Scribus to dělá - je již k dispozici pro Haiku. Jednoho dne přijde den, kdy budu moci poslat takový Chcete-li přidat podporu Haiku, přetáhněte požadavky na jiné projekty.

Jeden z vývojářů vysvětluje:

Pro ostatní projekty, které si přejí vytvářet balíčky samy, je podporována běžná metoda CMake/CPack. Jiné systémy sestavení lze podpořit přímým voláním programu sestavení balíčku, což je v pořádku, pokud o to lidé mají zájem. Zkušenosti ukazují: zatím nebyl velký zájem, takže haikuporter se nám osvědčil, ale nakonec by obě metody měly fungovat společně. Měli bychom představit sadu nástrojů pro cross-building software z Linuxu nebo jakéhokoli jiného serverového operačního systému (Haiku není navrženo pro běh na serverech).

Potlesk ve stoje. Běžní uživatelé Linuxu nesou veškerou tuto dodatečnou zátěž a další zavazadla (zabezpečení, přísná kontrola atd.), které jsou nezbytné pro serverový operační systém, ale ne pro osobní. Takže naprosto souhlasím s tím, že možnost vytvářet aplikace Haiku na Linuxu je správná cesta.

Závěr

Portování aplikací POSIX na Haiku je možné, ale může být dražší než typická přestavba. Určitě bych u toho zůstal na dlouho, nebýt pomoci lidí z kanálu #haiku na síti irc.freenode.net. Ale ani oni ne vždy hned viděli, co je špatně.

Snadnou výjimkou jsou aplikace napsané v Qt. Bez problémů jsem sestavil jednoduchou demo aplikaci.

Sestavení balíčku pro jednoduché aplikace je také celkem snadné, ale pouze pro ty „tradičně vydávané“, tzn. s verzovanými archivy zdrojového kódu určené pro podporu v haikuportech. Zdá se, že pro kontinuální sestavení (sestavení pro každé potvrzení změn) pomocí GitHubu není vše tak jednoduché. Zde Haiku působí spíše jako linuxová distribuce než jako výsledek na Macu, kde po kliknutí na tlačítko „Vytvořit“ v XCode získáte balíček .app, připravený k vložení do obrazu disku .dmg, připravené ke stažení na mém webu.
Nepřetržité budování aplikací založených na „serverovém“ operačním systému, například Linux, bude s největší pravděpodobností možné, pokud bude poptávka ze strany vývojářů, ale v tuto chvíli má projekt Haiku jiné, naléhavější úkoly.

Zkus to sám! Projekt Haiku koneckonců poskytuje vygenerované obrazy pro bootování z DVD nebo USB denní. Chcete-li nainstalovat, stačí stáhnout obrázek a zapsat jej na flash disk pomocí Etcher

Máte nějaké dotazy? Zveme vás na rusky mluvící telegramový kanál.

Přehled chyb: Jak se střelit do nohy v C a C++. Sbírka receptů Haiku OS

Z autor překlad: toto je pátý článek ze série o Haiku.

Seznam článků: první Druhý třetina Za čtvrté

Zdroj: www.habr.com

Můj pátý den s Haiku: pojďme portovat nějaké programy