🥇Мой пяты дзень з Haiku: давайце партуем трошкі праграм

TL, д-р: Навічок убачыў Haiku у першы раз, спрабуе партаваць некаторыя праграмы са свету Linux.

Мая першая партаваная для Haiku праграма, упакаваная ў яе фармат hpkg

Нядаўна я адкрыў для сябе Haiku, нечакана добрую аперацыйную сістэму для ПК.
Сёння я буду вучыцца пераносіць новыя праграмы на гэтую аперацыёнку. Асноўны ўпор – апісанне першага вопыту пераходу на Haiku з пункту гледжання распрацоўшчыка для Linux. Прашу прабачэння за дурныя памылкі, здзейсненыя ў працэсе, бо з таго часу, як я ўпершыню загрузіў Haiku, не прайшло і тыдня.

Я хачу дасягнуць трох мэт:

Партыраваць простае CLI дадатак
Партыраваць дадатак з GUI на Qt
Спакаваць іх потым у фармат hpkg (паколькі я ўсё яшчэ думаю пра адаптацыю AppDir і AppImage для Haiku…)

Прыступім. У раздзелах дакументацыя и распрацоўка, а таксама ў вікі ад HaikuPorts я знайшоў патрэбны напрамак. Ёсць нават анлайн кніга PDF BeOS: Партыраванне прыкладання Unix.
467 старонак - і гэта з 1997 года! Зазіраць унутр страшна, але спадзяюся на лепшае. Абнадзейваюць словы распрацоўніка: "доўга, таму што BeOS не была POSIX-сумяшчальнай", затое Haiku "па большай частцы" ужо такая.

Партыраванне простага прыкладання CLI

Першай думкай было партаваць дадатак аврчуд, але, як аказалася, гэта ўжо зрабілі даўным даўно.

Першая спроба: няма чаго глядзець

Чаго мне ніяк не зразумець, дык гэта таго, што ўжо больш за 10 гадоў прыкладання партуюцца для Haiku - пры тым, што самой АС яшчэ нават версіі 1.0 няма.

Другая спроба: трэба перапісаць

Такім чынам, я буду выкарыстоўваць ptouch-770, CLI для кіравання друкаркай Brother P-Touch 770, на якім я друкую этыкеткі.
Я на ім друкую розныя этыкеткі, і вы яго, магчыма, ужо бачылі ў мінулым артыкуле. Крыху раней я напісаў невялікую праграму-акрутку з GUI на Python (паколькі яна на Gtk+ — давядзецца перапісаць, а гэта добрая нагода падвучыцца).

Друкарка для этыкетак Brother P-Touch 770. Ці запрацуе пад Haiku?

Менеджэр пакетаў Haiku ведае пра бібліятэкі і каманды, таму калі я атрымліваю паведамленне "can't find libintl" пры запуску configure - проста запускаю pkgman install devel:libintl і патрэбны пакет будзе знойдзены. Аналагічна pkgman install cmd:rsync. Ну, і т.д.

За выключэннем выпадкаў, калі гэта не працуе:

/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

Магчыма udev занадта лінуксячы, таму не існуе для Haiku. Што азначае неабходнасць праўкі зыходнага кода, які я спрабую скампіляваць.
Эх, вышэй галавы не скокнеш, і я нават не ведаю, з чаго пачаць.

Трэцяя спроба

Было б нядрэнна мець tmate для Haiku, тады я дазволіў бы распрацоўшчыкам Haiku падлучацца да маёй тэрмінальнай сесіі - на выпадак, калі нешта пойдзе не так. Інструкцыі дастаткова простыя:

./autogen.sh
./configure
make
make install

Выглядае нядрэнна, ну дык чаму б і не паспрабаваць гэта на 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

На гэтым кроку я адкрываю HaikuDepot і шукаю curses.
Нешта знайшлося, што і дало мне падказку для больш пісьменнага запыту:

/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

Ізноў пайшоў у HaikuDepot, і, вядома ж, знайшоў devel:msgpack_c_cpp_devel. Што за дзіўныя імёны?

/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

На гэтым кроку я зразумеў, што перанос праграмы на Haiku патрабуе значна больш ведаў, чым трэба для простай перазборкі.
Я пагаварыў з прыязнымі распрацоўшчыкамі Haiku, аказалася, што ёсць памылка ў msgpack, а праз некалькі хвілін я бачу patch, у HaikuPorts. На свае вочы назіраю, як выпраўлены пакет збіраецца тут (buildslave - віртуальныя машыны).

Зборка выпраўленага msgpack на buildmaster

Паміж справай адпраўляю patch у upstream для дадання падтрымкі Haiku у msgpack.

Пяць хвілін праз абноўлены msgpack ужо даступны ў 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.

Нечакана добра. Гэта я сказаў?!

Вяртаюся зваротна да зыходнай задачы:

/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

Цяпер, падобна, msgpack не вінаваты. Каментую IMAXLABEL в tty.c так:

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

Вынік:

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.

Ну вось, зноў... Дарэчы:

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

mr. waddlesplash падказвае, куды капаць:

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

Тут я выклаў config.log.

Мне растлумачылі, што да libresolv на Haiku есць нешта яшчэ ў libnetwork. Па ўсёй бачнасці трэба далей кіраваць код. Трэба падумаць…

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

Адвечнае пытанне: што ж адбываецца.

/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

Тое самае, толькі ў профіль. Пагугліў і знайшоў гэта. Калі дадаць -lssp "часам" дапамагае, спрабую:

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

Ух ты! Яно запускаецца! Але...

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

Паспрабую адладзіць, файл тут:

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

«Bad port ID» - гэта ўжо як візітоўка хайку. Можа, нехта ўяўляе, што не так, і як гэта паправіць? Калі што, я абнаўлю артыкул. Спасылка на GitHub.

Партаванне GUI прыкладання на Qt.

Выбіраю простае дадатак 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!

Рэальна проста. Менш хвіліны!

Упакоўка прыкладанняў у hpkg выкарыстоўваючы haikuporter і haikuports.

З чаго б пачаць? Няма найпрасцейшай дакументацыі, іду на канал #haiku у irc.freenode.net і чую:

Каманда package - нізкаўзроўневы спосаб стварэння пакетаў. Па большай частцы ёй дастаткова PackageInfo, як апісана ў раздзеле "Making it into a proper. hpkg package"
Мне трэба зрабіць нешта такое
можна выкарыстоўваць hpkg-creator (у мяне вылятае, справаздача аб памылках)

Незразумела што рабіць. Мяркую, мне патрэбны дапаможнік для пачаткоўцаў у стылі «Прывітанне, Мір!», у ідэале - відэа. Было б нядрэнна яшчэ абзавесціся зручным увядзеннем у HaikuPorter, як зроблена ў GNU hello.

Чытаю наступнае:

haikuporter гэта прылада для стварэння агульных пакетных праектаў для Haiku. Ён выкарыстоўвае рэпазітар HaikuPorts у якасці базы для ўсіх пакетаў. Для стварэння пакетаў выкарыстоўваюцца рэцэпты haikuporter.

Дадаткова даведаюся, што:

Няма неабходнасці трымаць рэцэпты ў сховішча HaikuPorts. Можна зрабіць яшчэ адзін рэпазітар, змясціць у яго рэцэпты, пасля чаго паказаць haikuporter на яго.

Якраз тое, што мне трэба - калі не шукаць спосабу для публічнага размяшчэння пакета. Але гэта тэма для іншай пасады.

Ўстаноўка haikuporter і 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

Напісанне рэцэпта

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
}

Зборка рэцэпту

Захоўваю файл пад імем QtQuickApp-1.0.recipe, пасля чаго запускаю aikuporter -S ./QuickApp-1.0.recipe. Правяраюцца залежнасці для ўсіх пакетаў у рэпазітары haikuports, Што займае некаторы час. Пайду каву пап'ю.

А з якой нагоды гэтая праверка павінна рабіцца на маёй лакальнай машыне, а не цэнтралізавана на серверы 1 раз для ўсіх?

Згодна з mr. waddlesplash:

З такой, што можна перапісаць любы файл у рэпазітары 😉 Можна крыху аптымізаваць гэта, вылічаючы патрэбную інфармацыю тады, калі трэба, таму што апошнія зробленыя змены досыць рэдкія.

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

Аказваецца, не бывае звычайнага файла рэцэпта, у якім ёсць зыходны код вашага дадатку. Трэба трымаць яго ў рэпазітары ў фармаце HaikuPorts.

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

Гэты факт робіць зборку больш грувасткай. Мне гэта не асоба падабаецца, але думаю, яно трэба для таго, каб, у канчатковым выніку, усё ПЗ з адчыненым зыходным кодам з'явілася ў HaikuPorts.

Атрымліваю наступнае:

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

Што не так? Пасля чытання irc раблю:

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

Узнікла цікавае пытанне. Калі я дадам кантрольную суму ў рэцэпт - ці будзе яна адпавядаць апошняму git commit для бесперапыннай інтэграцыі? (Распрацоўшчык пацвярджае: "Нічога не выйдзе. Рэцэпты распрацаваны так, каб быць адносна стабільнымі").

Для прыколу дадаюць у рэцэпт:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Усё яшчэ не задавальняе:

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

Чаго гэта ён? Бо гэта рэпазітар git, код ужо тамака напроста, няма чаго распакоўваць. З майго пункту гледжання, інструмент павінен быць дастаткова разумным для таго, каб не шукаць распакоўшчык, калі яму над url з GitHub.

Магчыма спрацуе uri git://

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

Цяпер яно скардзіцца так:

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

Хм, і чаму ўсё так складана, чаму нельга "проста працаваць"? У рэшце рэшт не так ужо і рэдка можна нешта сабраць з GitHub. Ці то справа інструменты, якія працуюць адразу ж, без неабходнасці наладкі, ці як я гэта называю «валтузні».

Можа быць, спрацуе так:

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

Не-а. Усё яшчэ атрымліваю гэтую стремную памылку і раблю, як апісана тут

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

Прасоўваюся крыху далей, але чаму яно крычыць на мяне (GitHub-то не бяспечны!) і ўсё яшчэ спрабуе распакаваць нешта.

Згодна з mr. waddlesplash:

Так, прычынай паслужыла жаданне правяраць цэласнасць атрыманых для зборкі дадзеных. Адзін з варыянтаў - зверка кантрольнай сумы архіва, але можна, вядома, хэшаваць і асобныя файлы, што не будзе рэалізавана, т. да. гэта займае значна больш часу. Следствам гэтага і з'яўляецца небяспечнасць git і іншых VCS. Верагодней за ўсё так будзе заўсёды, паколькі стварыць архіў на GitHub дастаткова лёгка і часта хутчэй. Ну і ў будучыні, магчыма, паведамленне пра памылку не будзе такім крычаць… (мы больш не праводзім зліцця такіх рэцэптаў у HaikuPorts).

~/QtQuickApp> haikuporter -S QtQuickApp
Checking if any dependency-infos need to be updated ...
Looking for stale dependency-infos ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Downloading: git+https://github.com/probonopd/QtQuickApp.git ...
Warning: UNSAFE SOURCES ARE BAD AND SHOULD NOT BE USED IN PRODUCTION
Warning: PLEASE MOVE TO A STATIC ARCHIVE DOWNLOAD WITH CHECKSUM ASAP!
Cloning into bare repository '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
Unpacking source of QtQuickApp.git
tar: /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
Command 'git archive HEAD | tar -x -C "/boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0"' returned non-zero exit status 2

Па старой звычцы іду пытацца добрых людзей на канале #haiku у сетцы irc.freenode.net. І куды я без іх? Пасля падказкі зразумеў, што трэба выкарыстоўваць:

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

Добра, стала зразумела што яно робіць - пампуе архіў з зыходнікамі вызначанай рэвізіі. Дурное, з майго пункту гледжання, і не зусім тое, што хацелася, а менавіта - спампаваць апошнюю рэвізію з майстар-галінкі.

Адзін з распрацоўшчыкаў растлумачыў гэта так:

У нас ёсць свой CI, так што ўсё, што змяшчаецца ў рэпазітар haikuports, будзе збянтэжанае для ўсіх карыстальнікаў, а мы не хочам рызыкаваць збіраючы і пастаўляючы «ўсё апошняй версіі ў upstream».

Зразумеў! Ва ўсякім разе атрымалася такое:

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

Яно паўтарае так да бясконцасці. Мабыць, гэта памылка (ёсць заяўка? я не знайшоў).

С haikuporter і рэпазітаром haikuports не адчуваецца ўзроўню "проста працуе", але, як распрацоўшчыку, некаторыя рэчы ў працы з Haiku мне падабаюцца. Па большай частцы гэта падобна на Open Build Service - набор інструментаў для пабудовы зборак Linux: надзвычай магутны, з сістэмным падыходам, але залішні для майго дробнага прыкладання ўзроўню "hello world".

Ізноў жа, паводле mr. waddlesplash:

Сапраўды, HaikuPorter вельмі строгі па-змаўчанні (плюс маюцца рэжым lint, а таксама строгі рэжым, якія робяць яго яшчэ стражэйшым!), але толькі таму, што ён стварае пакеты, якія будуць працаваць, а не проста ствараць пакеты. Таму ён і лаецца на неабвешчаных залежнасцях, не імпартаваных належным чынам бібліятэках, няслушных версіях і да т.п. Мэта — адлавіць усе без выключэння праблемы, у тым ліку будучыя, да таго, як карыстальнік пра гэта даведаецца (таму не атрымалася ўсталяваць avrdude, бо ў рэцэпце фактычна была пазначана залежнасць). Бібліятэкі не проста асобныя пакеты і нават не пэўныя версіі SO. HaikuPorter сочыць за захаваннем усяго гэтага ў саміх рэцэптах, каб пазбегнуць памылак падчас выканання.

У прынцыпе такі ўзровень строгасці апраўданы пры стварэнні аперацыйнай сістэмы, але мне ён здаецца залішнім для прыкладання "hello world". Я вырашыў паспрабаваць што-небудзь яшчэ.

Зборка прыкладанняў у фармаце hpkg, выкарыстоўваючы каманду "package create"

Можа быць, гэтая простая інструкцыя падыдзе мне лепш?

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

Нечакана хутка, нечакана проста, нечакана эфектыўна. Дакладна так, як мне падабаецца, узрушаюча!

Ўстаноўка - што і куды?

Перамясціў файл QtQuickApp.hpkg у ~/config/packages, выкарыстоўваючы файлавы мэнэджар, пасля чаго QtQuickApp магічна з'явіўся ў ~/config/apps.
Ізноў жа нечакана хутка, проста і эфектыўна. Узрушаюча, неверагодна!

Але… (куды без іх!)

Прыкладанне ўсё яшчэ адсутнічае ў спісе меню прыкладанняў і ў QuickLaunch. Думаю, ужо ведаю, як гэта паправіць. У файлавым мэнэджары перамяшчаю QtQuickApp.hpkg з ~/config/packages у /system/packages.

Не-а, усё яшчэ адсутнічае. Па ўсёй бачнасці, я (ну, і інструкцыя) нешта прапусціў.

Агледзеўшы ўкладку "Contents" у HaikuDepot для некаторых іншых прыкладанняў я ўбачыў, што ёсць файлы выгляду /data/mimedb/application/x-vnd... што яшчэ характэрней, /data/deskbar/menu/Applications/….

Ну і што мне туды змясціць? Ану…

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

Суцэль упэўнены, што гэты трук пракоціць, але засталіся пытанні: навошта гэта трэба, для чаго гэта трэба? Па-мойму гэта разбурае агульнае ўражанне, што сістэма - такая вытанчаная.

Як растлумачыў mr. waddlesplash:

Часам ёсць прыкладанні, якія патрэбныя іншым прыкладанням, але не ў меню. Напрыклад, LegacyPackageInstaller на Вашым здымку экрана, які апрацоўвае архівы .pkg у фармаце BeOS. Жадаецца, каб карыстачы іх ставілі, але іх наяўнасць у меню прывядзе да блытаніны.

Мне чамусьці здаецца, што ёсць прасцейшае рашэнне, да прыкладу Hidden=true у файлах .desktop на Linux. Чаму б не зрабіць "ўтоеную" інфармацыю рэсурсам і атрыбутам файлавай сістэмы?

Што асабліва не вытанчана - назва (нейкага) прыкладання, якое паказвае меню, deskbar, жорстка прывязана ў шляху.

mr. waddlesplash з гэтай нагоды тлумачыць:

"Deskbar" у дадзеным выпадку варта разумець як нейкі агульны тэрмін (прыкладна гэтак жа, як "taskbar", які адносіцца як да дадатку Windows, так і да агульнай канцэпцыі). Ну а паколькі гэта deskbar, а не «Deskbar», гэта таксама можна разумець падобнай выявай.

2 "амаль ідэнтычных" каталога з прыкладаннямі ў іх

Чаму ёсць 2 каталога з прыкладаннямі, а таксама чаму ў адным мой QtQuickApplication ёсць, а ў іншым - не? (Бо гэта не адзін сістэмны, а другі карыстацкі, што асабіста мне было б зразумела).
Я рэальна заблытаўся і думаю, што трэба было б уніфікаваць гэта.

каментар mr. waddlesplash

У каталогу Apps ёсць прыкладанні, не патрэбныя ў меню. Але сітуацыю з меню насамрэч трэба палепшыць, зрабіць яго больш наладжвальным.

Заяўка, ці гэтага не здарыцца 😉

Я задумаўся: ці так неабходна размяшчаць прыкладанні ў /system/apps, калі карыстальнікам іх бачыць там - непажадана. Можа, лепш размясціць іх у іншым месцы, дзе карыстач з імі не будзе сутыкацца? Гэтак жа, як гэта зроблена ў Mac OS X, дзе змесціва пакетаў .app, якое не павінна быць відаць карыстальніку ў /Applications, хаваецца ў нетрах /System/Library/…«`.

Што наконт залежнасцяў?

Думаю, варта неяк указаць залежнасці, бо так? Ці можна лічыць Qt абавязковай часткай усталёўкі Haiku па-змаўчанні? Нэа! Qt па змаўчанні не ўсталяваны. Ці можа праграма зборкі пакета аўтаматычна вызначыць залежнасці праверыўшы файлы ELF? Мне сказалі, што HaikuPorter сапраўды так і робіць, а вось package не. Усё таму, што ён проста "зборшчык пакета", які сам па сабе проста стварае файлы hpkg.

Ці варта рабіць Haiku больш вытанчаным, дадаўшы палітыку, паводле якой у пакета не павінна быць залежнасцяў ад пакетаў, якія не ўваходзяць у haikuports? (Мне б так хацелася, паколькі падобная палітыка значна палягчае задачу - сістэма змагла б аўтаматычна дазволіць залежнасці кожнага пакета, загружанага адкуль заўгодна, без валтузні з дадатковымі крыніцамі пакетаў).

mr. waddlesplash тлумачыць:

Нам не хацелася б абмяжоўваць свабоду распрацоўшчыкам так моцна, бо відавочна, што калі КампаніяХ захоча падтрымаць свой уласны набор ПЗ з залежнасцямі (а такім чынам і рэпазітар) - яна цалкам свабодна зробіць гэта.

У такім разе магчыма варта парэкамендаваць пазбягаць іншым пакетам залежнасцяў ад чаго-небудзь, якое не ўваходзіць у haikuports, шляхам поўнага пакавання ўсяго неабходнага з дадаткам. Але, я думаю, гэта тэма для будучага артыкула ў гэтай сэрыі. [Аўтар хіліць да AppImage? - заўв. перакладчыка]

Даданне абразкі прыкладання

А што калі я жадаю дадаць у рэсурсы майго свежастворанага прыкладання адну з акуратненькіх убудаваных абразкоў? Аказваецца, гэта дзіўная тэма, так што яна стане асноўнай для наступнага артыкула.

Як арганізаваць бесперапынную зборку прыкладанняў?

Уявіце сабе праект, падобны на Inkscape (так, я ў курсе, што яго пакуль няма ў Haiku, але на ім зручна паказваць). У іх ёсць рэпазітар зыходнага кода https://gitlab.com/inkscape/inkscape.
Кожны раз, калі хтосьці фіксуе свае змены ў рэпазітары, запускаюцца канвееры зборкі, пасля чаго праўкі аўтаматычна тэстуюцца, збіраюцца, прыкладанне пакуецца ў розныя пакеты, уключаючы AppImage для Linux (аўтаномны пакет прыкладання, які можа быць загружаны для лакальнага тэсціравання незалежна ад таго , Што можа, ці не можа быць устаноўлена ў сістэме [я так і ведаў! - заўв. перакладчыка]). Аналагічна ўсё адбываецца пры кожным запыце на зліццё галінак, так што можна спампаваць дадатак, сабранае з кода, прапанаванага ў запыце на зліццё, яшчэ да зліцця.

Запыты на зліццё са статусамі зборкі і магчымасцю спампаваць сабраныя бінарнікі ў выпадку паспяховай зборкі (пазначана зялёным)

Зборка запускаецца ў кантэйнерах Docker. GitLab прапануе бясплатныя runners на Linux, да таго ж я думаю, што магчыма падключыць уласныя runners (дарэчы, я не ўяўляю, як гэта будзе працаваць для сістэм накшталт Haiku, якія, як я ведаю, не маюць Docker або аналага, але для FreeBSD таксама няма Docker, так што гэтая праблема не ўнікальная для Haiku).

У ідэальным выпадку зборка прыкладанняў для Haiku можа быць выканана ўнутры кантэйнера Docker для Linux. Пры такім раскладзе зборка для Haiku можа быць укаранёная ў існыя канвееры. Ёсць красакампілятары? Ці трэба эмуляваць усю Haiku усярэдзіне кантэйнера Docker, выкарыстаючы нешта тыпу QEMU/KVM (пры ўмове, што яно будзе так працаваць усярэдзіне Docker)? Дарэчы, многія праекты выкарыстоўваюць падобныя прынцыпы. Напрыклад, Scribus робіць так – ён ужо даступны для Haiku. Аднойчы настане дзень, калі я змагу адпраўляць такія запыты на зліццё ў іншыя праекты, каб дадаць у іх падтрымку Haiku.

Адзін з распрацоўшчыкаў тлумачыць:

Для іншых праектаў, ахвотнікаў ствараць пакеты самастойна, падтрымліваецца звычайны метад CMake/CPack. Іншыя сістэмы зборкі могуць быць падтрыманы, калі выклікаць праграму зборкі пакета напрамую, што добра, калі людзі будуць у гэтым зацікаўлены. Вопыт паказвае: да гэтага часу асаблівай цікавасці не было, так што haikuporter працаваў як зручна нам, але, у канчатковым выніку, абодва спосабы павінны працаваць сумесна. Нам варта прадставіць набор прылад для крыжаванай зборкі ПЗ з Linux ці любой іншай сервернай аперацыйнай сістэмы (Haiku не прызначаны для працы на серверах).

Апладырую стоячы. Звычайныя карыстачы Linux цягнуць усю гэтую дадатковую нагрузку і дадатковы багаж (бяспека, строгі кантроль і да т.п.), патрэбны сервернай аперацыёнцы, але не персанальнай. Таму я цалкам згодзен, што магчымасць збіраць прыкладанні для Haiku на Linux - правільны шлях.

Заключэнне

Партыраванне прыкладанняў POSIX на Haiku магчыма, але можа запатрабаваць больш выдаткаў, чым звычайная перазборка. Я б цалкам сапраўды завяз з гэтым надоўга, калі б не дапамога людзей з канала #haiku у сетцы irc.freenode.net. Але нават яны не заўжды адразу бачылі, што не так.

Прыкладанні, напісаныя на Qt, - лёгкае выключэнне. Я сабраў найпростае дэманстрацыйнае дадатак без асаблівых праблем.

Зборка пакета для простых прыкладанняў таксама досыць лёгкая, але толькі для "выпускаюцца традыцыйным спосабам", г.зн. якія маюць версіяваныя архівы зыходнага кода, прызначанага для падтрымкі ў haikuports. Для бесперапыннай зборкі (зборка на кожную фіксацыю змен) з GitHub усё накшталт не так проста. Тут Haiku больш адчуваецца аналагічна дыстрыбутыву Linux, чым выніку на Mаc, дзе пры націску кнопкі "Сабраць" у XCode атрымліваецца пакет .app, гатовы да ўстаўкі ў вобраз дыска .dmg, падрыхтаваны да загрузкі на маім сайце.
Бесперапынная зборка прыкладанняў на аснове "сервернай" аперацыёнкі, да прыкладу, Linux, хутчэй за ўсё стане магчымай, калі будзе попыт з боку распрацоўшчыкаў, але на дадзены момант у праекта Haiku ёсць іншыя, больш надзённыя задачы.

Паспрабуйце самі! Бо праект Haiku падае выявы для загрузкі з DVD ці USB, фармаваныя штодня. Для ўстаноўкі дастаткова спампаваць вобраз і запісаць яго на флэшку з дапамогай гравёр

Зьявіліся пытаньні? Запрашаем вас у рускамоўны telegram-канал.

Агляд памылак: Як стрэліць сабе ў нагу ў C і C ++. Зборнік рэцэптаў Haiku OS

Ад аўтара перакладу: гэта пяты артыкул з цыклу пра Haiku.

Спіс артыкулаў: Першая Другая трэцяя чацвёртая

Крыніца: habr.com

Мой пяты дзень з Haiku: давайце партуем трошкі праграм