🥇Môj piaty deň s Haiku: poďme portovať nejaké programy

TL; DR: Nováčik prvýkrát videl Haiku, keď sa pokúšal preniesť niektoré programy zo sveta Linuxu.

Môj prvý portovaný program Haiku, zabalený vo formáte hpkg

nedávno Objavil som Haiku, prekvapivo dobrý operačný systém pre PC.
Dnes sa naučím portovať nové programy do tohto operačného systému. Hlavným zameraním je popis prvých skúseností s prechodom na Haiku z pohľadu linuxového vývojára. Ospravedlňujem sa za všetky hlúpe chyby, ktorých som sa cestou dopustil, keďže neuplynul ani týždeň, odkedy som si Haiku prvýkrát stiahol.

Chcem dosiahnuť tri ciele:

Preneste jednoduchú aplikáciu CLI
Port aplikácie z GUI do Qt
Potom ich zabaľte do formátu hpkg (keďže stále uvažujem o prispôsobení AppDir a AppImage pre Haiku...)

Začnime. V sekciách dokumentáciu и rozvoj, ako aj v wiki z HaikuPorts som našiel správny smer. Existuje dokonca aj online kniha PDF BeOS: Portovanie unixovej aplikácie.
467 strán - a toto je z roku 1997! Je strašidelné pozerať sa dovnútra, ale dúfam v to najlepšie. Slová vývojára sú povzbudivé: „trvalo to dlho, pretože BeOS nebol kompatibilný s POSIX“, ale Haiku „väčšinou“ je už taký.

Portovanie jednoduchej aplikácie CLI

Prvou myšlienkou bolo preniesť aplikáciu AVRDude, ale, ako sa ukázalo, už je to tak urobili pred dlhým časom.

Prvý pokus: nie je čo pozerať

Čo už nedokážem pochopiť Aplikácie sa do Haiku prenášajú už viac ako 10 rokov - napriek tomu, že samotný OS ešte nemá ani verziu 1.0.

Druhý pokus: treba prepísať

Takže použijem ptouch-770, CLI na ovládanie tlačiarne Brother P-Touch 770, ktorú používam na tlač štítkov.
Tlačím naň rôzne štítky a možno ste ho už videli v predchádzajúcom článku. O niečo skôr som napísal malý GUI wrapper program v Pythone (keďže je v Gtk+, bude ho treba prepísať, a to je dobrý dôvod sa učiť).

Tlačiareň štítkov Brother P-Touch 770. Bude fungovať s Haiku?

Správca balíkov Haiku vie o knižniciach a príkazoch, takže ak pri spustení dostanem správu „nemôžem nájsť libintl“ configure - Práve spúšťam pkgman install devel:libintl a požadovaný balík sa nájde. Podobne pkgman install cmd:rsync. No atď.

Okrem prípadov, keď 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žno je udev príliš založený na Linuxe, a preto pre Haiku neexistuje. Čo znamená, že musím upraviť zdrojový kód, ktorý sa pokúšam skompilovať.
Eh, nemôžeš skákať po hlave a ja ani neviem, kde začať.

Tretí pokus

Bolo by pekné mať tmate pre Haiku by som vývojárom Haiku umožnil pripojiť sa k mojej terminálovej relácii - v prípade, že sa niečo pokazí. Návod je celkom jednoduchý:

./autogen.sh
./configure
make
make install

Vyzerá to dobre, tak prečo to neskúsiť 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 otvorím HaikuDepot a hľadám curses.
Našlo sa niečo, čo mi dalo tip na kompetentnejší 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

Opäť som išiel do HaikuDepot a, samozrejme, našiel devel:msgpack_c_cpp_devel. Čo sú to za zvláštne mená?

/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 som si uvedomil, že portovanie programu na Haiku si vyžaduje oveľa viac vedomostí, ako je potrebné na jednoduchú prestavbu.
Hovoril som s priateľskými vývojármi Haiku, ukázalo sa, že v msgpack je chyba a po niekoľkých minútach vidím opravu v HaikuPorts. Na vlastné oči vidím, ako bol opravený balík ísť sem (buildslave - virtuálne stroje).

Vytvorenie opraveného balíka msgpack na buildmaster

Medzitým posielam patch do upstreamu pridať podporu Haiku do msgpack.

O päť minút neskôr je aktualizovaný msgpack už 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čakane dobré. Povedal som to?!

Vrátim sa 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

Teraz to vyzerá, že msgpack nie je na vine. komentujem IMAXLABEL в tty.c nasledovne:

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

Výsledok:

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 ideme... Mimochodom:

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

Pán. waddlesplash povie vám, kde máte kopať:

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

Tu som uverejnil príspevok config.log.

Vysvetlili mi, že v libnetwork je okrem libresolv na Haiku aj niečo iné. Zrejme je potrebné kód ďalej upravovať. Treba myslieť…

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

Večná otázka: čo sa deje?

/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 isté, len v profile. Googled a našiel toto. Ak pridáte -lssp "niekedy" pomáha, skúšam:

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

Wow! Už to začína! Ale…

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

Skúsim odladiť súbor tu:

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

„Zlé ID portu“ je už ako vizitka haiku. Možno má niekto nápad, čo je zlé a ako to opraviť? Ak áno, aktualizujem článok. Odkaz na GitHub.

Prenos GUI aplikácie do Qt.

Vyberám si jednoduchú QML aplikáciu.

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

Naozaj jednoduché. Menej ako minútu!

Balenie aplikácií do hpkg pomocou haikuporter a haikuports.

S čím by som mal začať? Neexistuje jednoduchá dokumentácia, idem na kanál #haiku na irc.freenode.net a počujem:

Tím package - nízkoúrovňový spôsob vytvárania balíkov. Väčšinou jej stačí PackageInfo, ako je popísané v časti "Urob z toho poriadny .hpkg balík"
Potrebujem niečo urobiť toto
Môže sa použiť hpkg-creator (zrúti sa mi to, hlásenie chýb)

Nie je jasné, čo robiť. Asi potrebujem príručku pre začiatočníkov v štýle Hello World, ideálne video. Bolo by pekné mať tiež pohodlný úvod do HaikuPorter, ako sa to robí v GNU hello.

Prečítal som si nasledovné:

haikuporter je nástroj na vytváranie spoločných balíkových projektov pre Haiku. Používa úložisko HaikuPorts ako základ pre všetky balíčky. Recepty Haikuporter sa používajú na vytváranie balíčkov.

Okrem toho zisťujem, že:

Nie je potrebné ukladať recepty do úložiska HaikuPorts. Môžete vytvoriť ďalšie úložisko, vložiť doň recepty a potom naň nasmerovať haikuporter.

Presne to, čo potrebujem - ak nehľadám spôsob, ako verejne vydať balík. Ale toto je téma na iný príspevok.

Inštalácia 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

Písanie 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
}

Zostavenie receptu

Súbor ukladám pod menom QtQuickApp-1.0.recipe, po ktorom spustím aikuporter -S ./QuickApp-1.0.recipe. Závislosti sa kontrolujú pre všetky balíky v úložisku haikuporty, čo nejaký čas trvá. Idem si dať kávu.

Prečo by sa preboha mala táto kontrola vykonávať na mojom lokálnom počítači a nie centrálne na serveri raz pre každého?

Podľa p. waddlesplash:

S takým, že môžete prepísať akýkoľvek súbor v úložisku 😉 Môžete to trochu optimalizovať a v prípade potreby spočítať potrebné informácie, pretože posledné vykonané zmeny sú dosť zriedkavé.

~/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 sa, že neexistuje nič také ako bežný súbor receptov, ktorý by obsahoval zdrojový kód vašej aplikácie. Musíte ho uchovávať v úložisku vo formáte HaikuPorts.

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

Táto skutočnosť spôsobuje, že montáž je ťažkopádnejšia. Veľmi sa mi to nepáči, ale myslím si, že je to potrebné, aby sa nakoniec všetok softvér s otvoreným zdrojovým kódom objavil v HaikuPorts.

Dostanem nasledovné:

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

Čo je zle? Po prečítaní irc robí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 zaujímavá otázka. Ak do receptu pridám kontrolný súčet – bude sa zhodovať s najnovším odovzdaním git pre nepretržitú integráciu? (Vývojár potvrdzuje: "Nebude to fungovať. Recepty sú navrhnuté tak, aby boli relatívne stabilné.")

Pre zábavu pridajte do receptu:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Stále nie som spokojný:

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

Čo robí? Ide predsa o git repozitár, kód tam už priamo je, nie je čo rozbaľovať. Z môjho pohľadu by mal byť nástroj dostatočne inteligentný na to, aby nehľadal rozbaľovač, ak je nad adresou URL GitHubu.

Možno bude fungovať uri git://

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

Teraz sa sťažuje takto:

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

Hmm, prečo je všetko také komplikované, prečo nemôžete „len pracovať“? Koniec koncov, nie je to až také nezvyčajné, že sa dá niečo postaviť z GitHubu. Či už ide o nástroje, ktoré fungujú hneď, bez nutnosti nastavovania, alebo ako tomu hovorím „fušovanie“.

Možno to bude fungovať takto:

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

Nie. Stále dostávam túto zvláštnu chybu a robím, ako je tu popísané

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

Posúvam sa trochu ďalej, ale prečo to na mňa kričí (GitHub nie je zabezpečený!) a stále sa snaží niečo vybaliť.

Podľa Pán. waddlesplash:

Áno, dôvodom bola túžba skontrolovať integritu údajov prijatých na montáž. Jednou z možností je overenie kontrolného súčtu archívu, no jednotlivé súbory môžete samozrejme hašovať, čo sa neimplementuje, pretože trvá to oveľa dlhšie. Dôsledkom toho je „nebezpečnosť“ git a iných VCS. S najväčšou pravdepodobnosťou to tak bude vždy, pretože vytvorenie archívu na GitHub je pomerne jednoduché a často rýchlejšie. No v budúcnosti snáď nebude chybové hlásenie také honosné... (takéto recepty už v HaikuPorts nezluč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

Zo starého zvyku sa chodím pýtať dobrých ľudí na kanál #haiku v sieti irc.freenode.net. A kde by som bol bez nich? Po náznaku som si uvedomil, že by som mal použiť:

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

Dobre, bolo jasné, čo robí - sťahuje archív so zdrojovým kódom určitej revízie. Z môjho pohľadu je to hlúpe a nie presne to, čo som chcel, konkrétne stiahnuť najnovšiu revíziu z hlavnej vetvy.

Jeden z vývojárov to vysvetlil takto:

Máme vlastné CI, takže všetko, čo je umiestnené v úložisku haikuports, bude zabalené pre všetkých používateľov a nechceme riskovať zhromažďovanie a doručovanie „všetko v najnovšej verzii upstream“.

Rozumiem! V každom prípade sa 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 donekonečna. Zrejme ide o chybu (existuje nejaká aplikácia? Nenašiel som ju).

С haikuporter a úložisko haikuporty Nepôsobí to ako „len funguje“, ale ako vývojárovi sa mi na práci s Haiku páčia niektoré veci. Z väčšej časti je to podobné ako Open Build Service, súbor nástrojov na zostavovanie Linuxu: extrémne výkonný, so systematickým prístupom, ale premrštený pre moju malú aplikáciu „ahoj svet“.

Opäť podľa p. waddlesplash:

V skutočnosti je HaikuPorter štandardne dosť prísny (navyše existuje režim lint, ako aj striktný režim, aby bol ešte prísnejší!), ale len preto, že vytvára balíky, ktoré budú fungovať, a nie len vytváranie balíkov. Preto sa sťažuje na nedeklarované závislosti, nesprávne naimportované knižnice, nesprávne verzie atď. Cieľom je zachytiť všetky problémy, vrátane budúcich, skôr, ako sa o nich používateľ dozvie (preto nebolo možné nainštalovať avrdude, pretože závislosť bola skutočne špecifikovaná v recepte). Knižnice nie sú len jednotlivé balíčky alebo dokonca špecifické verzie SO. HaikuPorter zabezpečuje, aby sa toto všetko dodržiavalo v samotných receptoch, aby sa predišlo chybám počas vykonávania.

V zásade je táto úroveň prísnosti opodstatnená pri vytváraní operačného systému, ale pre aplikáciu „hello world“ sa mi zdá zbytočná. Rozhodol som sa skúsiť niečo iné.

Vytváranie aplikácií vo formáte hpkg pomocou príkazu „package create“.

Možno, toto Budú pre mňa jednoduché pokyny fungovať lepšie?

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čakane rýchle, nečakane jednoduché, nečakane efektívne. Presne ako sa mi to páči, úžasné!

Inštalácia - čo a kde?

Súbor QtQuickApp.hpkg bol presunutý do ~/config/packagespomocou správcu súborov, po ktorom sa zázračne objavila aplikácia QtQuickApp ~/config/apps.
Opäť nečakane rýchlo, jednoducho a efektívne. Úžasné, neuveriteľné!

Ale... (kde by sme bez nich boli!)

Aplikácia stále chýba v zozname aplikácií a QuickLaunch. Myslím, že už viem, ako to opraviť. V správcovi súborov presuniem QtQuickApp.hpkg z ~/config/packages do /system/packages.

Nie, stále chýba. Zrejme mi (no a návod) niečo uniklo.

Keď som sa pozrel na kartu „Obsah“ v HaikuDepot pre niektoré ďalšie aplikácie, videl som, že existujú súbory ako /data/mimedb/application/x-vnd... čo je ešte pozoruhodnejšie /data/deskbar/menu/Applications/….

No a čo tam mám dať? Poď...

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

Som si celkom istý, že tento trik bude fungovať, ale otázky zostávajú: prečo je to potrebné, na čo to je? Myslím, že to kazí celkový dojem, že systém je taký prepracovaný.

Ako vysvetlil p. waddlesplash:

Niekedy existujú aplikácie, ktoré iné aplikácie potrebujú, ale nie sú v ponuke. Napríklad LegacyPackageInstaller na snímke obrazovky, ktorý spracováva archívy .pkg vo formáte BeOS. Bol by som rád, keby si ich používatelia nainštalovali, ale ich prítomnosť v menu povedie k zmätku.

Z nejakého dôvodu sa mi zdá, že existuje jednoduchšie riešenie napr Hidden=true v súboroch .desktop v systéme Linux. Prečo neurobiť zo „skrytých“ informácií zdroj a atribút systému súborov?

Čo nie je obzvlášť jemné, je názov (nejakej) aplikácie, ktorá zobrazuje menu, deskbar, pevne zviazané po ceste.

Pán. waddlesplash vysvetľuje toto:

„Deskbar“ by sa v tomto prípade mal chápať ako druh všeobecného pojmu (v podstate rovnakým spôsobom ako „panel úloh“, ktorý sa vzťahuje na aplikáciu Windows aj na všeobecný koncept). No od tohto deskbar, nie „Deskbar“, to sa dá tiež chápať podobne.

2 "takmer identické" adresáre s aplikáciami v nich

Prečo sú tam 2 adresáre s aplikáciami a prečo je moja QtQuickApplication v jednom, ale nie v druhom? (Nejde predsa o jeden systémový, ale o druhý užívateľský, čo by bolo pre mňa osobne pochopiteľné).
Som naozaj zmätený a myslím si, že by sa to malo zjednotiť.

komentár od p. waddlesplash

Katalóg aplikácií obsahuje aplikácie, ktoré nie sú potrebné v ponuke. Situáciu s menu však skutočne treba zlepšiť, aby bolo lepšie prispôsobiteľné.

Aplikácia, inak sa to nestane 😉

Zaujímalo by ma: je skutočne potrebné hostiť aplikácie v /system/apps, ak ich tam používatelia uvidia, je to nežiaduce. Možno by bolo lepšie umiestniť ich na iné miesto, kde sa s nimi používateľ nestretne? Rovnako ako sa to robí v Mac OS X, kde je obsah balíkov .app, ktorý by nemal byť viditeľný pre používateľa v /Applications, ktorý sa skrýva v hlbinách /System/Library/…“`.

A čo závislosti?

Myslím, že stojí za to nejako špecifikovať závislosti, nie? Môže byť Qt štandardne považovaný za povinnú súčasť inštalácie Haiku? Nie! Qt nie je štandardne nainštalovaný. Môže tvorca balíkov automaticky zistiť závislosti kontrolou súborov ELF? Bolo mi povedané, že HaikuPorter to skutočne robí, ale package Nie Je to preto, že je to len „tvorca balíkov“, ktorý len sám vytvára súbory hpkg.

Malo by byť Haiku sofistikovanejšie pridaním zásady, že balík by nemal mať závislosti od balíkov mimo Haiku? haikuports? (Rád by som to urobil, pretože takáto politika by veci značne uľahčila – systém by bol schopný automaticky vyriešiť závislosti každého balíka stiahnutého odkiaľkoľvek, bez toho, aby sa zaoberal ďalšími zdrojmi balíkov.)

Pán. waddlesplash vysvetľuje:

Neradi by sme toľko obmedzovali slobodu vývojárov, pretože je zrejmé, že ak chce CompanyX podporovať vlastnú sadu softvéru so závislosťami (a teda úložisko), bude to robiť úplne slobodne.

V takom prípade by sa možno oplatilo odporučiť, aby sa balíky tretích strán vyhli závislosti od čohokoľvek, čo nie je zahrnuté v haikuportoch, a to úplným zabalením všetkého potrebného do aplikácie. Ale myslím si, že toto je téma pre budúci článok z tejto série. [Smeruje autor k AppImage? - približne. prekladateľ]

Pridanie ikony aplikácie

Čo ak chcem pridať jednu z úhľadných vstavaných ikon do zdrojov mojej novovytvorenej aplikácie? Ukazuje sa, že je to úžasná téma, takže bude základom pre ďalší článok.

Ako organizovať nepretržité zostavovanie aplikácií?

Predstavte si projekt ako Inkscape (áno, viem, že ešte nie je dostupný v Haiku, ale je vhodné ho na ňom zobraziť). Majú úložisko zdrojového kódu https://gitlab.com/inkscape/inkscape.
Zakaždým, keď niekto odovzdá svoje zmeny do úložiska, spustia sa zostavovacie kanály, po ktorých sa zmeny automaticky otestujú, zostavia a aplikácia sa zabalí do rôznych balíkov vrátane AppImage pre Linux (samostatný balík aplikácií, ktorý je možné stiahnuť na lokálne testovanie bez ohľadu na čo môže alebo nemusí byť nainštalované v systéme [Vedel som to! - približne. prekladateľ]). To isté sa stane s každou žiadosťou o zlúčenie pobočiek, takže pred zlúčením si môžete stiahnuť aplikáciu zostavenú z kódu navrhnutého v žiadosti o zlúčenie.

Zlúčiť požiadavky so stavmi zostavy a možnosťou stiahnuť skompilované binárne súbory, ak je zostava úspešná (označené zelenou farbou)

Zostava beží v kontajneroch Docker. GitLab ponúka bezplatných bežcov na Linuxe a myslím si, že by bolo možné zahrnúť aj vašich vlastných bežcov (mimochodom, neviem, ako by to fungovalo pre systémy ako Haiku, o ktorých viem, že nemajú Docker ani ekvivalent, ale tiež pre FreeBSD neexistuje Docker, takže tento problém nie je jedinečný pre Haiku).

V ideálnom prípade môžu byť aplikácie Haiku zabudované v kontajneri Docker pre Linux. V tejto situácii môže byť zostava pre Haiku zavedená do existujúcich potrubí. Existujú krížové kompilátory? Alebo by som mal emulovať všetky Haiku v kontajneri Docker pomocou niečoho ako QEMU / KVM (za predpokladu, že to bude fungovať v Dockeri)? Mimochodom, mnohé projekty využívajú podobné princípy. Napríklad Scribus to robí - už je k dispozícii pre Haiku. Jedného dňa príde deň, keď budem môcť poslať taký Stiahnutím žiadostí do iných projektov pridajte podporu Haiku.

Jeden z vývojárov vysvetľuje:

Pre iné projekty, ktoré chcú vytvárať balíčky sami, je podporovaná bežná metóda CMake/CPack. Ostatné zostavovacie systémy môžu byť podporované priamym volaním programu zostavovania balíkov, čo je dobré, ak o to ľudia majú záujem. Skúsenosti ukazujú: zatiaľ nebol veľký záujem, takže haikuporter nám vyhovoval, ale v konečnom dôsledku by obe metódy mali fungovať spolu. Mali by sme zaviesť sadu nástrojov pre cross-building softvér z Linuxu alebo akéhokoľvek iného serverového operačného systému (Haiku nie je určený na spustenie na serveroch).

Dávam veľký potlesk. Bežní používatelia Linuxu nesú všetku túto dodatočnú záťaž a ďalšiu batožinu (bezpečnosť, prísna kontrola atď.), ktorá je potrebná pre operačný systém servera, ale nie pre osobný. Takže úplne súhlasím s tým, že schopnosť vytvárať aplikácie Haiku na Linuxe je správna cesta.

Záver

Portovanie aplikácií POSIX na Haiku je možné, ale môže byť drahšie ako typické prebudovanie. Určite by som v tom zostal dlho, keby mi nepomohli ľudia z kanála #haiku na sieti irc.freenode.net. Ale ani oni nie vždy hneď videli, čo je zle.

Aplikácie napísané v Qt sú jednoduchou výnimkou. Bez problémov som dal dokopy jednoduchú demo aplikáciu.

Zostavenie balíka pre jednoduché aplikácie je tiež celkom jednoduché, ale len pre „tradične vydávané“, t.j. s verziou archívov zdrojového kódu určených na podporu v haikuportoch. Zdá sa, že pri nepretržitej zostave (vytvorenej pre každé odovzdanie zmien) s GitHub nie je všetko také jednoduché. Tu sa Haiku cíti skôr ako linuxová distribúcia než ako výsledok na Macu, kde po kliknutí na tlačidlo „Vybudovať“ v XCode získate balík .app, pripravený na vloženie do obrazu disku .dmg, pripravený na stiahnutie na mojej webovej stránke.
Nepretržité budovanie aplikácií založených na „serverovom“ operačnom systéme, napríklad Linux, bude s najväčšou pravdepodobnosťou možné, ak bude zo strany vývojárov dopyt, ale v súčasnosti má projekt Haiku iné, naliehavejšie úlohy.

Skúste to sami! Koniec koncov, projekt Haiku poskytuje vygenerované obrázky na zavedenie z DVD alebo USB denná. Ak chcete nainštalovať, stačí stiahnuť obrázok a zapísať ho na flash disk pomocou ten, kto leptá

Máte nejaké otázky? Pozývame vás na rusky hovoriaci telegramový kanál.

Prehľad chýb: Ako si vystreliť do nohy v C a C++. Zbierka receptov Haiku OS

Od autora preklad: toto je piaty článok zo série o Haiku.

Zoznam článkov: Prvé Druhý Третья štvrtý

Zdroj: hab.com

Môj piaty deň s Haiku: poďme portovať nejaké programy