Моят пети ден с 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“ при стартиране 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, а след няколко минути виждам пач в HaikuPorts. На живо наблюдавам как коригирания пакет се компилира тук (buildslave — виртуални машини).

Компилиране на коригирания msgpack на buildmaster

Междувременно изпращам пач в 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: предупреждение: неизползван параметър 'fd' [-Wunused-parameter]
 osdep_get_cwd(int fd)
               ~~~~^~
make: *** Няма правило за създаване на целта 'compat/forkpty-unknown.c', необходимо за '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 неуспешно търсене. Опитвам отново след 2 секунди (неотстраним проблем в разрешаването на името)

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

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

"Лош 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 и чувам:

• Команда пакет — нискоуровневен начин за създаване на пакети. По-голямата част от времето е достатъчно съобщението 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 приложение"
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, след което стартирам aikuporter -S ./QuickApp-1.0.recipe. Проверяват се зависимостите за всички пакети в хранилището haikuports, което отнема известно време. Ще отида да пия кафе.

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

Според г-н 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 OK
Дължина: неуточнена [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\/s) - ‘\/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/
( cd data/deskbar/menu/Applications ; ln -s ../../../../apps/QtQuickApp . )
package add QtQuickApp.hpkg apps data

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

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

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

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

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

г-н 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 наистина прави това, а пакет не. Всичко е, защото той е просто "сборщик на пакети", който сам по себе си създава файлове hpkg.

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

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

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

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

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

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

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

Представете си проект подобен на Inkscape (да, знам, че в момента го няма в Haiku, но е удобно да се показва). Те имат репозиторий на изходния код https://gitlab.com/inkscape/inkscape.
Всеки път, когато някой фиксва своите промени в репозитория, стартират pipelines за сглобяване, след което правките автоматично се тестват, сглобяват, а приложението се опакова в различни пакети, включително 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