🥇Мій п'ятий день з 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

Першою думкою було портувати програму avrdude, але, як виявилося, це вже зробили давним давно.

Перша спроба: нема чого дивитися

Чого мені ніяк не зрозуміти, то це того, що вже більше 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, ніж результату на Mac, де при натисканні кнопки «Зібрати» у XCode виходить пакет .appготовий до вставки в образ диска .dmg, підготовлений для завантаження на моєму сайті.
Безперервне складання додатків на основі «серверної» операційної системи, наприклад, Linux, швидше за все, стане можливим, якщо буде попит з боку розробників, але на даний момент у проекту Haiku є інші, більш нагальні завдання.

Спробуйте самі! Адже проект Haiku надає образи для завантаження з DVD або USB, що формуються щодня. Для встановлення достатньо завантажити образ та записати його на флешку за допомогою Etcher

Постали питання? Запрошуємо вас до російськомовної telegram-канал.

Огляд помилок: Як вистрілити собі в ногу у C та C++. Збірник рецептів Haiku OS

Від автора Переклад: це п'ята стаття з циклу про Haiku.

Список статей: перша Друга третя четверта

Джерело: habr.com

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