🥇Моят пети ден с Haiku: да преместим малко програми

TL;DR: Новакът видя Haiku за първи път и опитва да портва някои програми от света на Linux.

Моята първа портвана програма за Haiku, опакована в нейния формат hpkg

Наскоро Открих Haiku, неочаквано добра операционна система за ПК.
Днес ще уча да пренасям нови програми на тази операционна система. Основният акцент е описанието на първия опит за преминаване към Haiku от гледна точка на разработчиците за Linux. Извинявам се за глупавите грешки, направени в процеса, тъй като откакто за първи път заредих Haiku, не мина и седмица.

Искам да постигна три цели:

Да портвам прост CLI приложение
Да портвам приложение с GUI на Qt
След това да ги опаковам в формат hpkg (тъй като все още мисля за адаптиране на AppDir и AppImage за Haiku…)

Да започнем. В разделите документация и разработка, а също и в wiki от 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 знае за библиотеките и командите, така че, ако получа съобщение „не може да се намери libintl“ при стартиране конфигурирайте просто стартирам 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 да е твърде Linux-сходен, поради което не съществува за 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: В функция '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'.  Спри.

Ето го пак... Между другото:

/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. Retry in 2 seconds (non-recoverable failure in name resolution)

Ще опитам да отстраня проблема, файлът е тук:

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

«Bad port ID» — това вече звучи като визитка haiku. Може би някой може да предвиди какво не е наред и как мога да го поправя? Ако имам новини, ще обновя статията. Линк към 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 и чую:

Екип пакет — нискоуровневен начин за създаване на пакети. По принцип е достатъчно PackageInfo, както е описано в секцията «Правейки го правилен .hpkg пакет»
Трябва да направя нещо такова
Може да се използва 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/ # да може да се изпълнява от всякъде
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 е демонстрационно приложение QtQuick за тестване на портването и пакетизирането за Haiku"
HOMEPAGE="https://github.com/probonopd/QtQuickApp"
COPYRIGHT="Няма"
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, след което стартирам haikuporter -S ./QuickApp-1.0.recipe. Проверките на зависимостите за всички пакети в репозитория haikuports, което отнема известно време. Ще отида да пия кафе.

А защо тази проверка трябва да се прави на моята локална машина, а не централизирано на сървъра 1 път за всички?

Според г-н waddlesplash:

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

~/QtQuickApp> haikuporter QtQuickApp-1.0.recipe
Проверява дали нужните зависимости трябва да бъдат актуализирани ...
Търси остарели зависимости ...
Грешка: QtQuickApp не е намерен в репозитория

Оказва се, че няма обикновен файл рецепта, в който да има изходния код на приложението ви. Трябва да го съхранявате в репозитория във формат 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
Проверка дали има нужда от актуализация на зависимостите ...
        актуализиране на информацията за зависимостите на QtQuickApp-1.0
Търсене на остарели зависимости ...
Грешка: QtQuickApp-1.0.recipe не е намерен в дървото.

Какво не е наред? След като прочета irc, правя:

~\/QtQuickApp> haikuporter -S QtQuickApp
Проверка дали има нужда от актуализация на зависимостите ...
        актуализиране на информацията за зависимостите на QtQuickApp-1.0
Търсене на остарели зависимости ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe
----------------------------------------------------------------------
Изтегляне: https:\/\/github.com\/probonopd\/QtQuickApp.git ...
--2019-07-14 16:12:44--  https:\/\/github.com\/probonopd\/QtQuickApp.git
Разрешаване на github.com... 140.82.118.3
Свързване с github.com|140.82.118.3|:443... свързано.
HTTP заявка изпратена, чакаща отговор... 301 Преместено постоянно
Локация: https:\/\/github.com\/probonopd\/QtQuickApp [следване]
--2019-07-14 16:12:45--  https:\/\/github.com\/probonopd\/QtQuickApp
Повторно използване на съществуваща връзка към github.com:443.
HTTP заявка изпратена, чакаща отговор... 200 ОК
Дължина: неопределена [text\/html]
Запазване в: ‘\/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git’
     0K .                                                     1.34M=0.06s
2019-07-14 16:12:45 (1.34 MB\/с) - ‘\/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git’ запазен [90094]
Проверка на контролното число на QtQuickApp.git
Предупреждение: ----- ШАБЛОН ЗА КОНТРОЛНО ЧИСЛО -----
Предупреждение: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"
Предупреждение: -----------------------------
Грешка: Не намерено контролно число в рецептата!

Възникна интересен въпрос. Ако добавя контролно число в рецептата — дали ще съответства на последния git commit за непрекъсната интеграция? (Разработчикът потвърдил: „Нищо няма да се получи. Рецептите са проектирани да са относително стабилни“).

За забавление добавят в рецептата:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Все още не е доволно:

~\/QtQuickApp> haikuporter -S QtQuickApp
Проверка дали има нужда от актуализация на зависимостите ...
        актуализиране на информацията за зависимостите на QtQuickApp-1.0
Търсене на остарели зависимости ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe
----------------------------------------------------------------------
Пропускане на изтеглянето на източника за QtQuickApp.git
Проверка на контролното число на QtQuickApp.git
Разпакетиране на източника на QtQuickApp.git
Грешка: Неразпознат тип архив в файл \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git

Какво става? В крайна сметка, това е git хранилище, кодът вече е там директно, няма какво да се разпакова. Според мен инструментът трябва да е достатъчно умен, за да не търси разархиватор, ако е свързан с url от GitHub.

Може би ще сработи uri git:\/

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

Сега се оплаква така:

Изтегляне: git://github.com/probonopd/QtQuickApp.git ...
Грешка: Изтеглянето от небезопасни източници е забранено в 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
Проверявам дали трябва да се актуализират информацията за зависимостите ...
Търся остарели информационни зависимости ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Изтегляне: git+https://github.com/probonopd/QtQuickApp.git ...
Предупреждение: Небезопасните източници са лоши и не трябва да се използват в продукция
Предупреждение: Моля, преместете се на статично изтегляне на архив с контролна сума възможно най-скоро!
Клониране в чисто хранилище '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
Разопаковане на източника на QtQuickApp.git
tar: /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0: Не може да се отвори: Няма такъв файл или директория
tar: Грешката не може да се поправи: излизане сега
Команда 'git archive HEAD | tar -x -C "/boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0"' върна ненулев статус на изход 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".

Разбрах! Всъщност стана нещо такова:

чакане за активирането на пакет за компилация QtQuickApp-1.0-1
чакане за активирането на пакет за компилация QtQuickApp-1.0-1
чакане за активирането на пакет за компилация QtQuickApp-1.0-1
чакане за активирането на пакет за компилация QtQuickApp-1.0-1
чакане за активирането на пакет за компилация QtQuickApp-1.0-1
(...)

То се повтаря така до безкрайност. Явно е, че това е грешка (има заявка? Не намерих).

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

Отново, според г-н 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 "Демо приложение QtQuick"
description "QtQuickApp е демо приложение QtQuick за тестване на портването и опаковането на Haiku"

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# Вижте долу, ако също искате приложението
# да се появи в менюто

Неочаквано бързо, неочаквано просто, неочаквано ефективно. Точно така, както ми харесва, впечатляващо!

Инсталация — как и къде?

Преместих файла QtQuickApp.hpkg в ~\/config\/packages, използвайки файлов мениджър, след което QtQuickApp магически се появи в ~\/config\/apps.
Отново неочаквано бързо, просто и ефективно. Впечатляващо, невероятно!

Но… (къде без такива!)

Приложението все още отсъства от списъка с приложения и в QuickLaunch. Мисля, че вече знам как да го поправя. В файловия мениджър преместих QtQuickApp.hpkg от ~\/config\/packages в \/system\/packages.

Не, все още го няма. Очевидно съм пропуснал нещо (и инструкциите също).

След като прегледах таба „Съдържание“ в HaikuDepot за някои други приложения, видях, че има файлове от вида /data/mimedb/application/x-vnd... което е още по-забележително, /data/deskbar/menu/Applications/….

Ами, какво да сложа там? Хайде да видим…

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

Сигурен съм, че този трик ще проработи, но имам въпроси: защо е необходимо, за какво е необходимо? Според мен това разваля общото впечатление, че системата е такава изтънчена.

Както обясни г-н waddlesplash:

Има приложения, които са нужни на други приложения, но не в менюто. Например, LegacyPackageInstaller на вашия екран, който обработва архиви .pkg в BeOS формат. Бих искал потребителите да ги инсталират, но присъствието им в менюто ще доведе до объркване.

Някак си ми се струва, че има по-просто решение, например Hidden=true в файловете .desktop на Linux. Защо да не направим „скритата“ информация ресурс и атрибут на файловата система?

Нещо, което особено не е изтънчено — името (на някое) приложение, което показва менюто, deskbar, е физически свързано в пътя.

Г-н waddlesplash по този въпрос обяснява:

„Deskbar“ в този случай трябва да се разбира като общ термин (приблизително така, както „taskbar“, отнасящ се както до Windows приложение, така и до общата концепция). А тъй като това deskbar, а не „Deskbar“, също може да се разбира по подобен начин.

2 „почти идентични“ каталога с приложения в тях

Защо има 2 каталога с приложения, а също така защо в един мой QtQuickApplication съществува, а в другия — не? (В крайна сметка това не е единствен системен, а вторият потребителски, което на мен лично би било ясно).
Наистина се обърках и мисля, че е необходимо да се унифицира това.

коментар на г-н waddlesplash

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

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

Замислих се: дали е необходимо да се разполагат приложения в /system/apps, ако потребителите не желаят да ги виждат там? Може би е по-добре да ги поставим на друго място, където потребителят няма да се сблъска с тях? Както е направено в Mac OS X, където съдържанието на пакетите .app, което не трябва да бъде видимо за потребителя в /Applications, се крие в недрата /System/Library/…«.`

Какво става със зависимостите?

Мисля, че трябва да посочим зависимостите, нали? Може ли да се приема, че Qt е задължителна част от инсталацията на Haiku по подразбиране? Не! Qt не е инсталиран по подразбиране. Може ли пакетният сборщик автоматично да определи зависимостите, като провери ELF файловете? Казаха ми, че HaikuPorter наистина го прави, а тук пакет не. Всичко е, защото той е просто 'пакетен сборщик', който сам по себе си само създава файлове hpkg.

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

mr. waddlesplash обяснява:

Не искаме да ограничаваме свободата на разработчиците толкова силно, тъй като е очевидно, че ако КомпанияХ желае да поддържа свой собствен набор от софтуер със зависимости (и следователно репозиториум) — тя напълно свободно може да го направи.

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

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

А какво ще стане, ако искам да добавя в ресурсите на новосъздаденото си приложение една от сладките вградени иконки? Оказва се, че това е удивителна тема, така че тя ще бъде основна за следващата статия.

Как да организираме непрекъснато изграждане на приложения?

Представете си проект, подобен на Inkscape (да, знам, че все още го няма в Haiku, но е удобно да се покаже). Те имат репозиторий на изходния код https://gitlab.com/inkscape/inkscape.
Всеки път, когато някой запази промените си в репозитория, се задействат сборни конвейри, след което корекциите се тестват автоматично, приложението се опакова в различни пакети, включително AppImage за Linux (самостоятелен пакет на приложението, който може да бъде изтеглен за локално тестване независимо от това какво може или не може да бъде инсталирано в системата. [Знаех си! — бел. на преводача]). По сходен начин протича всичко при всяко искане за сливане на клонове, така че можете да изтеглите приложението, събрано от кода, предложен в искането за сливане, дори преди самото сливане.

Исканията за сливане с статуси на сглобяване и възможност за изтегляне на събраните бинарни файлове в случай на успешно сглобяване (обозначено в зелено).

Сглобяването започва в Docker контейнери. GitLab предлага безплатни runner-и на Linux и смятам, че е възможно да се свържат собствени runner-и (между другото, не мога да си представя как ще работи това за системи като 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

Имате въпроси? Каним ви в рускоезичния телеграм канал.

Преглед на грешките: Как да си простреляте крака в C и C++. Сборник рецепти на Haiku OS

От автор превод: това е петата статия от серията за Haiku.

Списък на статиите: Първа Втора Трети Четвърта

Източник: habr.com