🥇Můj pátý den s Haiku: pojďme portovat trochu programů

TL;DR: Nováček poprvé viděl Haiku a pokouší se portovat některé programy ze světa Linuxu.

Moje první aplikace portovaná pro Haiku, zabalena do formátu hpkg.

Nedávno Objevil jsem Haiku, neočekávaně dobrý operační systém pro PC.
Dnes se budu učit, jak přenášet nové programy na tento operační systém. Hlavní důraz je na popis prvního přechodu na Haiku z pohledu vývojáře pro Linux. Omlouvám se za hlouposti, které jsem udělal během procesu, protože od doby, co jsem poprvé nahrál Haiku, neuplynul ani týden.

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

Portovat jednoduchou CLI aplikaci.
Portovat aplikaci s GUI na Qt.
Poté je zabalit do formátu hpkg (protože stále zvažuji přizpůsobení AppDir a AppImage pro Haiku ...)

Začněme. V sekcích dokumentace a vývoj, stejně jako v wiki na HaikuPorts jsem našel správný směr. Dokonce existuje online kniha ve formátu PDF. BeOS: Portování aplikace Unix..
467 stran — a to už od roku 1997! Dívání se dovnitř je zastrašující, ale doufám v to nejlepší. Povzbuzují mě slova vývojáře: „trvá to dlouho, protože BeOS nebyl kompatibilní s POSIX“, ale Haiku je „většinou“ už taková.

Portování jednoduché CLI aplikace.

První myšlenka byla portovat aplikaci avrdude., ale jak se ukázalo, už je to přispěli už dlouho.

První pokus: není co ukazovat.

Co si nemohu nijak vysvětlit, je to, že už více než 10 let se aplikace portují pro Haiku, přitom samotný OS ještě ani nemá verzi 1.0.

Druhý pokus: je potřeba přepsat.

Takže budu používat ptouch-770,CLI pro správu tiskárny Brother P-Touch 770, na které tisknu štítky.
Na něm tisknu různé štítky a možná jste jej viděli v předchozím článku. Chvíli předtím jsem napsal malý obalový program s GUI na Pythonu (protože je na Gtk+ — budu muset přepsat, a to je dobrá příležitost, jak se něco naučit).

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

Správce balíčků Haiku ví o knihovnách a příkazech, takže pokud dostanu zprávu „can’t find libintl“ při spuštění, konfigurovat prostě spustím pkgman install devel:libintl a potřebný balíček bude nalezen. Podobně pkgman install cmd:rsync.No, atd.

S výjimkou 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š linuxový, a proto neexistuje pro Haiku. Což znamená nutnost úpravy zdrojového kódu, který se snažím zkompilovat.
Ach, přes hlavu neskáču, a ani nevím, odkud začít.

Třetí pokus.

Bylo by dobré mít tmate pro Haiku, pak bych povolil vývojářům Haiku připojit se k mé terminálové relaci — pro případ, že by něco šlo špatně. Instrukce jsou dost jednoduché:

.\/autogen.sh
.\/configure
make
make install

Vypadá to dobře, 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írám HaikuDepot a hledám curses.
Něco se našlo, co mi dalo tip na lepší 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ě jsem 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 přenos programu na Haiku vyžaduje mnohem více znalostí, než je potřeba pro jednoduchou rekompilaci.
Povídal jsem si s přátelskými vývojáři Haiku a zjistil jsem, že je v msgpack chyba, a za pár minut vidím patch v HaikuPorts. Na vlastní oči sleduji, jak se opravený balíček sestavuje zde (buildslave — virtuální stroje).

Sestavení opraveného msgpack na buildmaster

Mezitím posílám patch do upstream pro přidání podpory Haiku do msgpack.

Pět minut po aktualizaci je msgpack už k dispozici 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.

Nepředvídatelně dobře. To jsem řekl?!

Vrátím se zpět k původnímu úkolu:

/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

Teď to vypadá, že msgpack není na vině. Komentuju IMAXLABEL v tty.c takto:

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

Result:

osdep-unknown.c: V funkci 'osdep_get_cwd':
osdep-unknown.c:32:19: warning: unused parameter 'fd' [-Wunused-parameter]
 osdep_get_cwd(int fd)
               ~~~~^~
make: *** No rule to make target 'compat/forkpty-unknown.c', needed by 'compat/forkpty-unknown.o'.  Stop.

No tak a je to zase... Mimochodem:

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

mr. waddlesplash dává vědět, kam hledat:

/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 dal config.log.

Bylo mi vysvětleno, že k libresolv na Haiku je něco dalšího v libnetwork. Zřejmě je potřeba dále upravit kód. Musím popřemýšlet...

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

Večná otázka: co se vlastně 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. Googluji a našel jsem to. Pokud přidám -lssp "někdy" to pomáhá, zkouším:

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

Hezky! Spouští se to! Ale...

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

Zkusím to odladit, soubor je zde:

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

"Bad port ID" — to už vypadá jako vizitka haiku. Možná někdo ví, co je špatně a jak to opravit? Pokud něco, aktualizuji článek. Odkaz na GitHub.

Portování GUI aplikace na Qt.

Vybral jsem jednoduchou aplikaci QML.

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

Skutečně jednoduché. Méně než jednu minutu!

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

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

Tým balíček — nízkoúrovňový způsob vytváření balíčků. Většinou stačí PackageInfo, jak je popsáno v části „Jak vytvořit správný .hpkg balíček“
Musím něco udělat takové
Lze použít hpkg-creator (rád bych se vyhnul pádům, hlášení o chybě)

Není jasné, co dělat. Myslím, že potřebuji příručku pro začátečníky ve stylu „Ahoj, světe!“, ideálně video. Bylo by také fajn mít pohodlný úvod do HaikuPorter, tak jak je to uděláno v GNU hello.

Čtu následující:

haikuporter je nástroj pro vytváření obecných balíčkových projektů pro Haiku. Používá repozitář HaikuPorts jako základ pro všechny balíčky. K vytvoření balíčků se používají recepty haikuporter.

Dále zjištuji, že:

Není nutné uchovávat recepty v úložišti HaikuPorts. Můžete vytvořit další repozitář, vložit do něj recepty a poté na něj ukázat haikuporter.

To je přesně to, co potřebuji — pokud nehledejte způsob, jak veřejně zveřejnit balíček. Ale to je téma pro 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/ # udělejte to spustitelné odkudkoli
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

Napsání receptu

SUMMARY="Demo QtQuick application"
DESCRIPTION="QtQuickApp je demo aplikace QtQuick pro testování portování a balení Haiku"
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í receptu

Ukládám soubor pod názvem QtQuickApp-1.0.recipe, poté spouštím aikuporter -S ./QuickApp-1.0.recipe. Kontrolují se závislosti pro všechny balíčky v repozitáři haikuports, což trvá nějakou dobu. Jdu si udělat kávu.

A proč by tato kontrola měla probíhat na mém místním počítači, a ne centrálně na serveru jednou pro všechny?

Podle pana waddlesplash:

S tím, že můžete přepsat jakýkoli soubor v repozitáři 😉 Můžeme to mírně optimalizovat tím, že budeme počítat potřebné informace, když to bude nutné, protože poslední provedené změny jsou dost vzácné.

~/QtQuickApp> haikuporter QtQuickApp-1.0.recipe
Kontrola, zda je potřeba aktualizovat jakékoli informace o závislostech ...
Hledání zastaralých informací o závislostech ...
Chyba: QtQuickApp nebyl nalezen v repozitáři

Ukazuje se, že neexistuje žádný běžný soubor receptu, ve kterém je zdrojový kód vaší aplikace. Musíte ho uchovat v repozitáři ve formátu HaikuPorts.

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

Tento fakt činí sestavení více komplikovaným. Nelíbí se mi to moc, ale myslím, že je to nezbytné, aby nakonec všechna softwarová řešení s otevřeným zdrojovým kódem byla dostupná v HaikuPorts.

Získávám následující:

~ /QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe
Kontrola, zda je potřeba aktualizovat informace o závislostech ...
        aktualizace informací o závislostech QtQuickApp-1.0
Hledání zastaralých informací o závislostech ...
Chyba: QtQuickApp-1.0.recipe nebyl nalezen v adresářové struktuře.

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

~ /QtQuickApp> haikuporter -S QtQuickApp
Kontrola, zda je potřeba aktualizovat informace o závislostech ...
        aktualizace informací o závislostech QtQuickApp-1.0
Hledání zastaralých informací o závislostech ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot /home /haikuports /app-misc /QtQuickApp /QtQuickApp-1.0.recipe
----------------------------------------------------------------------Stahování: https://github.com/probonopd/QtQuickApp.git ...
--2019-07-14 16:12:44--  https://github.com/probonopd/QtQuickApp.git
Řešení github.com... 140.82.118.3
Připojení k github.com|140.82.118.3|:443... připojeno.
HTTP požadavek byl odeslán, čeká na odpověď... 301 Trvale přesunuto
Umístění: https://github.com/probonopd/QtQuickApp [sledování]
--2019-07-14 16:12:45--  https://github.com/probonopd/QtQuickApp
Znovu používám existující připojení k github.com:443.
HTTP požadavek byl odeslán, čeká na odpověď... 200 OK
Délka: neurčeno [text / html]
Ukládání do: ‘/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’ uloženo [90094]
Ověřování kontrolního součtu QtQuickApp.git
Varování: ----- ŠABLONA KONTROLNÍHO SOČTU -----
Varování: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"
Varování: -----------------------------
Chyba: Nebyl nalezen kontrolní součet v receptu!

Vzniká zajímavá otázka. Pokud do receptu přidám kontrolní součet — bude odpovídat poslednímu git commitu pro kontinuální integraci? (Vývojář potvrzuje: „Nic nebude fungovat. Recepty jsou navrženy tak, aby byly relativně stabilní“).

Pro zábavu přidávají do receptu:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Stále to není v pořádku:

~ /QtQuickApp> haikuporter -S QtQuickApp
Kontrola, zda je potřeba aktualizovat informace o závislostech ...
        aktualizace informací o závislostech QtQuickApp-1.0
Hledání zastaralých informací o závislostech ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot /home /haikuports /app-misc /QtQuickApp /QtQuickApp-1.0.recipe
----------------------------------------------------------------------
Přeskakuji stahování zdroje pro QtQuickApp.git
Ověřování kontrolního součtu QtQuickApp.git
Rozbalování zdroje QtQuickApp.git
Chyba: Neznámý typ archivu v souboru /boot /home /haikuports /app-misc /QtQuickApp /download /QtQuickApp.git

Proč se to děje? Vždyť je to git repozitář, kód tam už je přímo, není co rozbalovat. Z mého pohledu by nástroj měl být dost chytrý na to, aby nehledal rozbalovač, pokud mu dáte URL z GitHubu.

Možná to zafunguje jako uri git://

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

Teď si stěžuje takto:

Stahuji: git://github.com/probonopd/QtQuickApp.git ...
Chyba: Stahování z nebezpečných zdrojů je zakázáno v haikuports.conf!

Hm, proč je to všechno tak složité, proč nemůže „jen fungovat“? Koneckonců, není to zas tak vzácné, něco sestavit z GitHubu. Pořád mám raději nástroje, které fungují okamžitě bez potřeby nastavení, nebo jak říkám, „šachování“.

Možná to bude fungovat takto:

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

Ne. Pořád dostávám tu otravnou chybu a dělám to, jak je popsáno zde

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

Trochu se posunu dál, ale proč na mě pořád křičí (GitHub přece není bezpečný!) a stále se snaží něco rozbalit.

Podle mr. waddlesplash:

Ano, důvodem je touha kontrolovat integritu dat určených pro sestavení. Jednou z možností je kontrola kontrolního součtu archivu, ale dá se samozřejmě hashovat i jednotlivé soubory, což nebude realizováno, protože to zabere mnohem více času. A tímto vzniká „nebezpečnost“ gitu a dalších VCS. Pravděpodobně to tak bude vždy, protože vytvořit archiv na GitHubu je dost snadné a často rychlejší. A v budoucnu, možná, nebude chybová zpráva tak křičící… (už neslučujeme takové recepty v HaikuPorts).

~QtQuickApp> haikuporter -S QtQuickApp
Kontrola, zda je potřeba aktualizovat některé informace o závislostech ...
Hledání zastaralých informací o závislostech ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Stahuji: git+https://github.com/probonopd/QtQuickApp.git ...
Varování: NEBEZPEČNÉ ZDROJE JSOU ŠPATNÉ A NEMĚLY BY BÝT POUŽÍVÁNY V PRODUKCI
Varování: PROSÍM PŘEJDĚTE NA STABILNÍ ARCHIVOVÉ STAHOVÁNÍ S KONTROLNÍM SOUČTEM CO NEJDŘÍVE!
Klonování do prázdného repozitáře '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
Rozbalování zdroje z QtQuickApp.git
tar: /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0: Nelze otevřít: Žádný takový soubor nebo adresář
tar: Chyba nelze opravit: aplikace nyní končí
Příkaz 'git archive HEAD | tar -x -C "/boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0"' vrátil stav 2

Podle starého zvyku jdu se ptát hodných lidí na kanálu #haiku v síti irc.freenode.net. A kam bych se bez nich dostal? Po radě jsem pochopil, že musím použít:

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

Dobře, je jasné, co dělá — stahuje archiv se zdrojovými kódy určité revize. Z mého pohledu je to hloupé a není to úplně to, co bych chtěl, konkrétně — stáhnout poslední revizi z hlavní větve.

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

Máme vlastní CI, takže vše, co se vloží do repozitáře haikuports, bude zabalené pro všechny uživatele, a nechceme riskovat sbíráním a dodáváním „všech posledních verzí v upstreamu“.

Rozumím! Každopádně to vypadá takto:

čekání na aktivaci balíčku QtQuickApp-1.0-1
čekání na aktivaci balíčku QtQuickApp-1.0-1
čekání na aktivaci balíčku QtQuickApp-1.0-1
čekání na aktivaci balíčku QtQuickApp-1.0-1
čekání na aktivaci balíčku QtQuickApp-1.0-1
(...)

Ono to opakuje tak donekonečna. Zřejmě je to chyba (existuje nějaký tiket? Nenašel jsem).

S haikuporter a repozitářem haikuports Není tu pocit úrovně „prostě to funguje“, ale jako vývojáři mám rád některé věci při práci s Haiku. Většinou to připomíná Open Build Service — soubor nástrojů pro vytváření sestavení Linuxu: extrémně mocné, se systémovým přístupem, ale zbytečné pro mou drobnou aplikaci úrovně „hello world“.

Opět podle pana waddlesplash:

Opravdu, HaikuPorter je ve výchozím nastavení velmi přísný (navíc existují režimy lint a přísný režim, které ho dělají ještě přísnějším!), ale pouze proto, že vytváří balíčky, které budou fungovat, a ne jen tak vytváří balíčky. Proto také vyžaduje neoznámené závislosti, nepřiměřeně importované knihovny, nesprávné verze atd. Cílem je zachytit všechny problémy bez výjimky, včetně budoucích, dříve, než se o nich uživatel dozví (proto nebylo možné nainstalovat avrdude, protože v receptu byla ve skutečnosti uvedena závislost). Knihovny nejsou jen jednotlivé balíčky a ani ne určité verze SO. HaikuPorter sleduje dodržování toho všeho v samotných receptech, aby se předešlo chybám při provádění.

V zásadě je taková úroveň přísnosti opodstatněná při vytváření operačního systému, ale pro aplikaci „hello world“ mi přijde zbytečná. Rozhodl jsem se vyzkoušet něco jiného.

Sestavení aplikací ve formátu hpkg pomocí příkazu „package create“

Možná, tento jednoduchý návod by mi vyhovoval 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

Nepředvídatelně rychle, nepředvídatelně snadno, nepředvídatelně efektivně. Přesně tak, jak to mám rád, úžasné!

Instalace — co a kam?

Přesunul jsem soubor QtQuickApp.hpkg do ~\/config\/packages, pomocí správce souborů, po čemž se QtQuickApp magicky objevila v ~\/config\/apps.
Opět nepředvídatelně rychle, snadno a efektivně. Úžasné, neuvěřitelné!

Ale… (kam bez nich!)

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

Ne, stále chybí. Zřejmě jsem (no, a návod) něco přehlédl.

Při prohlížení záložky „Obsah“ v HaikuDepot pro některé další aplikace jsem viděl, že jsou tam soubory typu /data/mimedb/application/x-vnd... což je zajímavější, /data/deskbar/menu/Applications/….

No a co tam mám dát? Tak tedy…

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

Jsem si docela jistý, že tento trik vyjde, ale zůstávají otázky: proč je to potřeba, k čemu je to potřeba? Podle mě to narušuje celkový dojem, že systém je takový sofistikovaný.

Jak vysvětlil mr. waddlesplash:

Někdy jsou aplikace, které potřebují jiné aplikace, ale ne v menu. Například LegacyPackageInstaller na vašem snímku obrazovky, který zpracovává archivy .pkg ve formátu BeOS. Rád bych, aby je uživatelé instalovali, ale jejich přítomnost v menu by způsobila zmatek.

Mám pocit, že existuje jednodušší řešení, například Hidden=true v souborech .desktop v Linuxu. Proč tedy neudělat „skryté“ informace zdrojem a atributem souborového systému?

Což není příliš sofistikované — název (nějaké) aplikace, která zobrazuje menu, deskbar, je pevně svázán v cestě.

mr. waddlesplash k tomu dodává:

„Deskbar“ zde má být chápáno jako určitý obecný termín (podobně jako „taskbar“, který se vztahuje jak na aplikaci Windows, tak na obecnou koncepci). No a protože to je deskbar, a ne „Deskbar“, lze to chápat podobným způsobem.

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

Proč existují dva adresáře s aplikacemi, a proč mám ve svém QtQuickApplication jeden a v druhém ne? (Vždyť to není jeden systémový, ale druhý uživatelský, což by mi osobně dávalo smysl).
Opravuji, jsem zmatený a myslím, že by bylo dobré to sjednotit.

komentář mr. waddlesplash

V adresáři Apps jsou aplikace, které nejsou potřebné v nabídce. Ale situaci s nabídkou je opravdu potřeba zlepšit, udělat ji více přizpůsobitelnou.

Žádost, nebo se to nestane 😉

Zamyslel jsem se: je opravdu nutné umísťovat aplikace do /system/apps, pokud je pro uživatele nežádoucí je tam vidět. Možná by bylo lepší umístit je na jiné místo, kde se s nimi uživatel nesetká? Stejně jako je to uděláno v Mac OS X, kde se obsah balíčků .*.app, který by uživatelům neměl být viditelný v /Applications, skrývá v hlubinách /System/Library/…

Co závislosti?

Myslím, že je dobré nějakým způsobem uvést závislosti, že? Může být Qt považován za povinnou součást instalace Haiku ve výchozím nastavení? Ne! Qt není ve výchozím nastavení nainstalován. Může program pro sestavení balíčku automaticky určit závislosti prozkoumáním souborů ELF? Říkali mi, že HaikuPorter to skutečně dělá, ale balíček ne. Všechno protože je to prostě „sestavovač balíčku“, který sám o sobě pouze vytváří soubory hpkg.

Měli bychom udělat Haiku sofistikovanější tím, že přidáme politiku, podle které by balíček neměl mít závislosti na balíčcích, které nejsou součástí haikuports? (Мне бы так хотелось, поскольку подобная политика значительно облегчает задачу — система смогла бы автоматически разрешить зависимости каждого пакета, загружаемого откуда угодно, без возни с дополнительными источниками пакетов).

mr. waddlesplash vysvětluje:

Nehodláme takto omezovat svobodu vývojářů, protože je zřejmé, že pokud by SpolečnostX chtěla podporovat svou vlastní sadu softwaru se závislostmi (a tím i repozitář) — může to udělat naprosto svobodně.

V takovém případě by bylo možná dobré doporučit, aby se třetí balíčky vyhýbaly závislostem na čemkoli, co není součástí haikuports, prostřednictvím kompletního zabalení všeho potřebného s aplikací. Ale, myslím, že toto je téma pro budoucí článek v této sérii. [Autor naznačuje AppImage? — pozn. překladatele]

Přidání ikony aplikace

A co když chci přidat do zdrojů mé nově vytvořené aplikace jednu z elegantních vestavěných ikon? Ukazuje se, že je to fascinující téma, takže se stane hlavním tématem pro další článek.

Jak organizovat kontinuální sestavení aplikací?

Představte si projekt podobný Inkscape (ano, vím, že zatím není v Haiku, ale je to výhodné na předvádění). Mají repozitář zdrojového kódu. https://gitlab.com/inkscape/inkscape.
Každýkrát, když někdo uloží své změny do repozitáře, spustí se buildovací procesy, po kterých se úpravy automaticky testují, sestavují, a aplikace se balí do různých balíčků, včetně AppImage pro Linux (autonomní balíček aplikace, který lze stáhnout pro lokální testování bez ohledu na to, co může nebo nemůže být nainstalováno v systému). [věděl jsem to! — pozn. překladatele]). Podobně to probíhá při každém požadavku na sloučení větví, takže si můžete stáhnout aplikaci sestavenou z kódu navrhovaného v požadavku na sloučení ještě před sloučením.

Požadavky na sloučení se stavy sestavení a možností stáhnout sestavené binární soubory v případě úspěšného sestavení (označeno zeleně).

Sestavení se spouští v kontejnerech Docker. GitLab nabízí bezplatné běžce na Linuxu, navíc si myslím, že je možné připojit vlastní běžce (mimochodem, nedokážu si představit, jak to bude fungovat pro systémy jako Haiku, které, jak vím, nemají Docker nebo ekvivalent, ale pro FreeBSD také není Docker, takže tento problém není jedinečný pro Haiku).

Ideálně by sestavení aplikací pro Haiku mohlo probíhat uvnitř kontejneru Docker pro Linux. V takovém případě by sestavení pro Haiku mohlo být integrováno do stávajících buildovacích procesů. Existují kroskompilátory? Nebo je nutné emulovat celé Haiku uvnitř kontejneru Docker, pomocí něčeho jako QEMU/KVM (pokud to tak bude fungovat uvnitř Dockeru)? Mimochodem, mnoho projektů používá podobné principy. Například Scribus to dělá — už je k dispozici pro Haiku. Jednou nastane den, kdy budu moci odesílat takové požadavky na sloučení do dalších projektů, abych do nich přidal podporu pro Haiku.

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

Pro další projekty, které si přejí vytvářet balíčky samy, se podporuje běžná metoda CMake/CPack. Mohou být podporovány i jiné systémy sestavení, pokud je zavolána program pro sestavení balíčku přímo, což je dobré, pokud by o to lidé měli zájem. Zkušenosti ukazují, že dosud žádný zvláštní zájem nebyl, takže haikuporter fungoval, jak nám to vyhovuje, ale nakonec by měly obě cesty fungovat společně. Měli bychom představit sadu nástrojů pro křížové sestavení softwaru z Linuxu nebo jakékoliv jiné serverové operační systém (Haiku není určen pro serverové použití).

Tleskám ve stoje. Běžní uživatelé Linuxu nesou veškerou tu dodatečnou zátěž a další břemeno (bezpečnost, přísnou kontrolu atd.), které je potřebné pro serverový operační systém, ale ne pro osobní. Proto plně souhlasím, že schopnost sestavovat aplikace pro Haiku na Linuxu je správnou cestou.

Závěr

Portování aplikací POSIX na Haiku je možné, ale může vyžadovat více nákladů než běžné přestavění. Zcela určitě bych se tím dlouho nezabýval, nebýt pomoci lidí z kanálu #haiku na síti irc.freenode.net. Ale ani oni ne vždy hned viděli, co není v pořádku.

Aplikace napsané v Qt jsou snadné výjimky. Sestavil jsem nejjednodušší demonstrační aplikaci bez zvláštních problémů.

Sestavení balíčku pro jednoduché aplikace je také dost snadné, ale pouze pro "vydávané tradičním způsobem", tj. mají verzi archivů zdrojového kódu určeného pro podporu v haikuports. Pro nepřetržité sestavení (sestavení na každou revizi) z GitHubu to vypadá tak jednoduché. Zde se Haiku více podobá distribuci Linuxu než výsledku na Macu, kde kliknutím na tlačítko „Sestavit“ v XCode získáte paket .*.app, připravený k vložení do obrazového disku .dmg, připravený k nahrání na mé stránce.
Nepřetržité sestavení aplikací na základě "serverového" operačního systému, například Linuxu, se pravděpodobně stane možným, pokud bude poptávka ze strany vývojářů, ale v tuto chvíli má projekt Haiku jiné, naléhavější úkoly.

Vyzkoušejte to sami! Projekt Haiku poskytuje obrazy pro spuštění z DVD nebo USB, které jsou vytvářeny denně. Pro instalaci stačí stáhnout obraz a zapsat ho na flash disk pomocí Etcher

Máte otázky? Zveme vás do rusky mluvícího telegramového kanálu.

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

Od autora překlad: to je pátý článek ze série o Haiku.

Seznam článků: První Druhý Třetí Čtvrtá

Zdroj: habr.com