СофтХабрахабр

[Перевод] Мой пятый день с Haiku: давайте портируем немножко программ

TL;DR: Новичок увидел Haiku в первый раз, пробует портировать некоторые программы из мира Linux.


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

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

Я хочу достичь трех целей:

  • Портировать простое CLI приложение
  • Портировать приложение с GUI на Qt
  • Упаковать их потом в формат hpkg (поскольку я все еще думаю об адаптации AppDir и AppImage для Haiku...)

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

Портирование простого приложения CLI

Первой мыслью было портировать приложение avrdude, но, как оказалось, это уже сделали давным-давно.

Первая попытка: нечего смотреть

0 нет. Чего мне никак не понять, так это того, что уже более 10 лет приложения портируются для Haiku — при том, что самой ОС еще даже версии 1.

Вторая попытка: нужно переписать

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

Заработает ли под Haiku?
Принтер для этикеток Brother P-Touch 770.

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

За исключением случаев, когда это не работает:

/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

Воочию наблюдаю, как исправленный пакет собирается здесь (buildslave — виртуальные машины). На этом шаге я осознал, что перенос программы на Haiku требует значительно больше знаний, чем нужно для простой пересборки.
Я поговорил с дружелюбными разработчиками Haiku, оказалось, что есть ошибка в msgpack, а через несколько минут я вижу patch, в HaikuPorts.


Сборка исправленного 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

Комментирую IMAXLABEL в tty.c так: Сейчас, похоже, msgpack не виновен.

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

waddlesplash подсказывает, куда копать: mr.

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

Читаю следующее:

Он использует репозиторий HaikuPorts в качестве базы для всех пакетов. haikuporter это инструмент для создания общих пакетных проектов для Haiku. Для создания пакетов используются рецепты haikuporter.

Дополнительно узнаю, что:

Можно сделать еще один репозиторий, поместить в него рецепты, после чего указать haikuporter на него. Нет необходимости держать рецепты в хранилище HaikuPorts.

Но это тема для другого поста. Как раз то, что мне нужно — если не искать способа для публичного размещения пакета.

Установка 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
}

Сборка рецепта

0.recipe, после чего запускаю aikuporter -S ./QuickApp-1. Сохраняю файл под именем QtQuickApp-1. Проверяются зависимости для всех пакетов в репозитории haikuports, что занимает некоторое время. 0.recipe. Пойду-ка кофейку попью.

А с какой стати эта проверка должна делаться на моей локальной машине, а не централизованно на сервере 1 раз для всех?

waddlesplash: Согласно mr.

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

~/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-то не безопасный!) и все еще пытается распаковать что-то.

waddlesplash: Согласно mr.

Один из вариантов — сверка контрольной суммы архива, но можно, конечно, хешировать и отдельные файлы, что не будет реализовано, т.к. Ну да, причиной послужило желание проверять целостность получаемых для сборки данных. Следствием этого и является "небезопасность" git и других VCS. это занимает гораздо больше времени. Ну и в будущем, возможно, сообщение об ошибке не будет таким кричащим… (мы больше не проводим слияния таких рецептов в HaikuPorts). Вероятнее всего так будет всегда, поскольку создать архив на GitHub достаточно легко и часто быстрее.

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

Видимо, это ошибка (есть заявка? Оно повторяет так до бесконечности. я не нашел).

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

waddlesplash: Опять же, согласно mr.

Поэтому он и ругается на необъявленных зависимостях, не импортированных должным образом библиотеках, неверных версиях и т.п. Действительно, HaikuPorter весьма строгий по-умолчанию (плюс имеются режим lint, а также строгий режим, делающие его еще более строгим!), но только потому, что он создает пакеты, которые будут работать, а не просто создавать пакеты. Библиотеки не просто отдельные пакеты и даже не определенные версии SO. Цель — отловить все без исключения проблемы, включая будущие, до того, как пользователь об этом узнает (поэтому не получилось установить avrdude, ведь в рецепте фактически была указана зависимость). 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

По-моему это разрушает общее впечатление, что система — такая утонченная. Вполне уверен, что этот трюк прокатит, но остались вопросы: зачем это нужно, для чего это нужно?

waddlesplash: Как пояснил mr.

К примеру, LegacyPackageInstaller на Вашем снимке экрана, обрабатывающий архивы .pkg в формате BeOS. Иногда есть приложения, которые нужны другим приложениям, но не в меню. Хочется, чтобы пользователи их ставили, но их наличие в меню приведет к путанице.

Почему бы не сделать "скрытую" информацию ресурсом и атрибутом файловой системы? Мне почему-то кажется, что есть более простое решение, к примеру Hidden=true в файлах .desktop на Linux.

Что особенно не утонченно — название (некоего) приложения, показывающего меню, deskbar, жестко привязано в пути.

waddlesplash по этому поводу поясняет: mr.

Ну а поскольку это deskbar, а не "Deskbar", это тоже можно понимать схожим образом. "Deskbar" в данном случае следует понимать как некий общий термин (примерно так же, как "taskbar", относящийся как к приложению Windows, так и к общей концепции).


2 "почти идентичных" каталога с приложениями в них

(Ведь это не один системный, а второй пользовательский, что лично мне было бы понятно).
Я реально запутался и думаю, что надо бы унифицировать это. Почему есть 2 каталога с приложениями, а также почему в одном мой QtQuickApplication есть, а в другом — нет?

waddlesplash комментарий mr.

Но ситуацию с меню в самом деле надо улучшить, сделать его более настраиваемым. В каталоге Apps есть приложения, не нужные в меню.

Заявка, или этого не случится 😉

Может, лучше разместить их в другом месте, где пользователь с ними не будет сталкиваться? Я задумался: так ли необходимо размещать приложения в /system/apps, если пользователям их видеть там — нежелательно. Так же, как это сделано в Mac OS X, где содержимое пакетов .app, которое не должно быть видно пользователю в /Applications, прячется в недрах /System/Library/...```.

Что насчет зависимостей?

Можно ли считать Qt обязательной частью установки Haiku по-умолчанию? Думаю, стоит как-то указать зависимости, ведь так? Qt по умолчанию не установлен. Неа! Мне сказали, что HaikuPorter действительно так и делает, а вот package нет. Может ли программа сборки пакета автоматически определить зависимости проверив файлы ELF? Все потому, что он просто "сборщик пакета", который сам по себе просто создает файлы hpkg.

(Мне бы так хотелось, поскольку подобная политика значительно облегчает задачу — система смогла бы автоматически разрешить зависимости каждого пакета, загружаемого откуда угодно, без возни с дополнительными источниками пакетов). Стоит ли делать Haiku утонченнее, добавив политику, согласно которой у пакета не должно быть зависимостей от пакетов, не входящих в haikuports?

waddlesplash поясняет: mr.

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

Но, я думаю, это тема для будущей статьи в этой серии. В таком случае возможно стоило бы порекомендовать избегать сторонним пакетам зависимостей от чего-либо, не входящего в haikuports, путем полной упаковки всего необходимого с приложением. — прим. [Автор клонит к AppImage? переводчика]

Добавление иконки приложения

Оказывается, это удивительная тема, так что она станет основной для следующей статьи. А что если я хочу добавить в ресурсы моего свежесозданного приложения одну из аккуратненьких встроенных иконок?

Как организовать непрерывную сборку приложений?

У них есть репозиторий исходного кода https://gitlab.com/inkscape/inkscape.
Каждый раз, когда кто-то фиксирует свои изменения в репозитории, запускаются конвейеры сборки, после чего правки автоматически тестируются, собираются, приложение упаковывается в различные пакеты, включая AppImage для Linux (автономный пакет приложения, который может быть загружен для локального тестирования независимо от того, что может, или не может быть установлено в системе [я так и знал! Представьте себе проект, подобный Inkscape (да, я в курсе, что его пока нет в Haiku, но на нем удобно показывать). переводчика]). — прим. Аналогично все происходит при каждом запросе на слияние веток, так что можно скачать приложение, собранное из кода, предложенного в запросе на слияние, еще до слияния.


Запросы на слияние со статусами сборки и возможностью скачать собранные бинарники в случае успешной сборки (помечена зеленым)

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

При таком раскладе сборка для Haiku может быть внедрена в существующие конвейеры. В идеальном случае сборка приложений для Haiku может быть выполнена внутри контейнера Docker для Linux. Или надо эмулировать всю Haiku внутри контейнера Docker, используя что-то типа QEMU/KVM (при условии, что оно будет так работать внутри Docker)? Есть кросскомпиляторы? Например, Scribus делает так — он уже доступен для Haiku. Кстати, многие проекты используют схожие принципы. Однажды наступит день, когда я смогу отправлять такие запросы на слияние в другие проекты, чтобы добавить в них поддержку Haiku.

Один из разработчиков поясняет:

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

Обычные пользователи Linux тащат всю эту дополнительную нагрузку и дополнительный багаж (безопасность, строгий контроль и т.п.), нужный серверной операционке, но не персональной. Аплодирую стоя. Поэтому я полностью согласен, что возможность собирать приложения для Haiku на Linux — правильный путь.

Заключение

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

Я собрал простейшее демонстрационное приложение без особых проблем. Приложения, написанные на Qt, — легкое исключение.

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

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

Приглашаем вас в русскоязычный telegram-канал. Появились вопросы?

Сборник рецептов Haiku OS Обзор ошибок: Как выстрелить себе в ногу в C и C++.

От автора перевода: это пятая статья из цикла про Haiku.

Список статей: Первая Вторая Третья Четвертая

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть