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

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

Първата ми пренесена програма Haiku, пакетирана в своя hpkg формат

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

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

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

Да започваме. В секции документация и развитие, както и в уики от HaikuPorts намерих правилната посока. Има дори онлайн PDF книга BeOS: Пренасяне на Unix приложение.
467 страници - и това е от 1997 г.! Страшно е да погледна вътре, но се надявам на най-доброто. Думите на разработчика са окуражаващи: „отне много време, защото BeOS не беше POSIX-съвместим“, но Haiku „в по-голямата си част“ вече е такъв.

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

Първата мисъл беше да пренеса приложението avrdude, но, както се оказа, това вече е Свършен преди много време.

Първи опит: нищо за гледане

Това, което не мога да разбера е, че вече Приложенията са пренесени в Haiku повече от 10 години - въпреки факта, че самата операционна система все още дори не е версия 1.0.

Втори опит: трябва да се пренапише

Така че ще използвам тъч-770, CLI за управление на принтера Brother P-Touch 770, който използвам за печат на етикети.
Отпечатвам различни етикети върху него и може би вече сте го виждали в предишната статия. Малко по-рано написах малка програма GUI wrapper на 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 е твърде базиран на 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 и след няколко минути виждам корекция в 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: 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 казва ви къде да копаете:

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

Обясниха ми, че има нещо друго в libnetwork в допълнение към libresolv на Haiku. Очевидно кодът трябва да бъде редактиран допълнително. Трябва да се мисли…

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

Същото нещо, само в профил. Googled и намери това. Ако добавите -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

„Лош идентификатор на порт“ вече е като визитна картичка хайку. Може би някой има идея какво не е наред и как да го поправя? Ако е така, ще актуализирам статията. Връзка към 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 е достатъчен за нея, както е описано в раздела „Превръщане в подходящ .hpkg пакет“
трябва да направя нещо такое
Може да използва hpkg-създател (при мен се срива, докладване на грешки)

Не е ясно какво да правя. Предполагам, че имам нужда от ръководство за начинаещи в стил Hello World, в идеалния случай видео. Би било хубаво да има и удобно въведение в HaikuPorter, както се прави в GNU hello.

Чета следното:

haikuporter е инструмент за създаване на общи пакетни проекти за Haiku. Той използва хранилището на HaikuPorts като основа за всички пакети. Рецептите на Haikuporter се използват за създаване на пакети.

Освен това откривам, че:

Няма нужда да съхранявате рецепти в хранилището на HaikuPorts. Можете да направите друго хранилище, да поставите рецептите в него и след това да посочите haikuporter към него.

Точно това, от което се нуждая - ако не търся начин за публично пускане на пакета. Но това е тема за друг пост.

Инсталиране на haikuporter и haikuports

cd /boot/home/
git clone https://github.com/haikuports/haikuporter --depth=50
git clone https://github.com/haikuports/haikuports --depth=50
ln -s /boot/home/haikuporter/haikuporter /boot/home/config/non-packaged/bin/ # make it runnable from anywhere
cd haikuporter
cp haikuports-sample.conf /boot/home/config/settings/haikuports.conf
sed -i -e 's|/mydisk/haikuports|/boot/home/haikuports|g' /boot/home/config/settings/haikuports.conf

Писане на рецепта

SUMMARY="Demo QtQuick application"
DESCRIPTION="QtQuickApp is a demo QtQuick application for testing Haiku porting and packaging"
HOMEPAGE="https://github.com/probonopd/QtQuickApp"
COPYRIGHT="None"
LICENSE="MIT"
REVISION="1"
SOURCE_URI="https://github.com/probonopd/QtQuickApp.git"
#PATCHES=""
ARCHITECTURES="x86_64"
PROVIDES="
    QtQuickApp = $portVersion
"
REQUIRES="
    haiku
"
BUILD_REQUIRES="
    haiku_devel
    cmd:qmake
"BUILD()
{
    qmake .
    make $jobArgs
}INSTALL()
{
    make install
}

Сглобяване на рецептата

Запазвам файла под името QtQuickApp-1.0.recipe, след което стартирам aikuporter -S ./QuickApp-1.0.recipe. Зависимостите се проверяват за всички пакети в хранилището хайкупортове, което отнема известно време. Отивам да пия кафе.

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

Според г-н. waddlesplash:

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

~/QtQuickApp> haikuporter  QtQuickApp-1.0.recipe
Checking if any dependency-infos need to be updated ...
Looking for stale dependency-infos ...
Error: QtQuickApp not found in repository

Оказва се, че няма такова нещо като обикновен файл с рецепта, който да съдържа изходния код на вашето приложение. Трябва да го съхранявате в хранилище във формат HaikuPorts.

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

Този факт прави сглобяването по-тромаво. Не ми харесва особено, но мисля, че е необходимо, така че в крайна сметка целият софтуер с отворен код да се появи в HaikuPorts.

Получавам следното:

~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe
Checking if any dependency-infos need to be updated ...
        updating dependency infos of QtQuickApp-1.0
Looking for stale dependency-infos ...
Error: QtQuickApp-1.0.recipe not found in tree.

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

~/QtQuickApp> haikuporter -S QtQuickApp
Checking if any dependency-infos need to be updated ...
        updating dependency infos of QtQuickApp-1.0
Looking for stale dependency-infos ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Downloading: https://github.com/probonopd/QtQuickApp.git ...
--2019-07-14 16:12:44--  https://github.com/probonopd/QtQuickApp.git
Resolving github.com... 140.82.118.3
Connecting to github.com|140.82.118.3|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://github.com/probonopd/QtQuickApp [following]
--2019-07-14 16:12:45--  https://github.com/probonopd/QtQuickApp
Reusing existing connection to github.com:443.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git’
     0K .                                                     1.34M=0.06s
2019-07-14 16:12:45 (1.34 MB/s) - ‘/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git’ saved [90094]
Validating checksum of QtQuickApp.git
Warning: ----- CHECKSUM TEMPLATE -----
Warning: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"
Warning: -----------------------------
Error: No checksum found in recipe!

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

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

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

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

~/QtQuickApp> haikuporter -S QtQuickApp
Checking if any dependency-infos need to be updated ...
        updating dependency infos of QtQuickApp-1.0
Looking for stale dependency-infos ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------
Skipping download of source for QtQuickApp.git
Validating checksum of QtQuickApp.git
Unpacking source of QtQuickApp.git
Error: Unrecognized archive type in file /boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git

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

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

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

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

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

Хм, защо всичко е толкова сложно, защо не можете „просто да работите“? В крайна сметка не е толкова необичайно да се изгради нещо от GitHub. Независимо дали става дума за инструменти, които работят веднага, без необходимост от настройка или както аз го наричам "суетене".

Може би ще работи така:

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

не Все още получавам тази странна грешка и правя, както е описано тук

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

Придвижвам се малко по-нататък, но защо ми крещи (GitHub не е защитен!) и все още се опитва да разопакова нещо.

Според г-н. waddlesplash:

Е, да, причината беше желанието да се провери целостта на данните, получени за сглобяване. Една от опциите е да проверите контролната сума на архива, но можете, разбира се, да хеширате отделни файлове, което няма да бъде реализирано, т.к. отнема много повече време. Последицата от това е „несигурността“ на git и други VCS. Това най-вероятно винаги ще бъде така, тъй като създаването на архив в GitHub е доста лесно и често по-бързо. Е, в бъдеще може би съобщението за грешка няма да е толкова блестящо... (вече не обединяваме такива рецепти в HaikuPorts).

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

По стар навик отивам да питам добри хора в канала #haiku в мрежата irc.freenode.net. И къде щях да съм без тях? След подсказката разбрах, че трябва да използвам:

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

Добре, стана ясно какво прави - изтегля архив със сорс кода на дадена ревизия. Глупаво е от моя гледна точка и не е точно това, което исках, а именно да изтегля последната ревизия от главния клон.

Един от разработчиците го обясни по следния начин:

Имаме собствен CI, така че всичко, което е поставено в хранилището на haikuports, ще бъде пакетирано за всички потребители и не искаме да рискуваме да събираме и доставяме „всичко в най-новата версия нагоре по веригата“.

Разбрах! Във всеки случай това се случи:

waiting for build package QtQuickApp-1.0-1 to be activated
waiting for build package QtQuickApp-1.0-1 to be activated
waiting for build package QtQuickApp-1.0-1 to be activated
waiting for build package QtQuickApp-1.0-1 to be activated
waiting for build package QtQuickApp-1.0-1 to be activated
(...)

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

С haikuporter и хранилище хайкупортове Няма усещане за „просто работи“, но като разработчик има някои неща, които харесвам в работата с Haiku. В по-голямата си част той е подобен на Open Build Service, набор от инструменти за изграждане на компилации на Linux: изключително мощен, със систематичен подход, но прекалено много за моето малко приложение „здравей свят“.

Отново според г-н. waddlesplash:

Наистина, HaikuPorter е доста строг по подразбиране (плюс това има режим на мъх, както и строг режим, за да стане още по-строг!), но само защото създава пакети, които ще работят, вместо просто да създава пакети. Ето защо той се оплаква от недекларирани зависимости, неправилно импортирани библиотеки, неправилни версии и т.н. Целта е да се уловят всички проблеми, включително бъдещи, преди потребителят да разбере за тях (ето защо не беше възможно да се инсталира avrdude, защото зависимостта всъщност беше посочена в рецептата). Библиотеките не са само отделни пакети или дори конкретни SO версии. HaikuPorter гарантира, че всичко това се спазва в самите рецепти, за да се избегнат грешки по време на изпълнение.

По принцип това ниво на строгост е оправдано при създаването на операционна система, но ми се струва ненужно за приложение „здравей свят“. Реших да опитам нещо друго.

Изграждане на приложения във формат 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.

Не, все още липсва. Явно аз (е, и инструкциите) съм пропуснал нещо.

След като разгледах раздела „Съдържание“ в 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 е в едната, но не и в другата? (В крайна сметка това не е системен, а втори потребителски, което лично за мен би било разбираемо).
Наистина съм объркан и мисля, че това трябва да бъде унифицирано.

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

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

Приложение, или няма да стане 😉

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

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

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

Трябва ли Haiku да бъде направено по-сложно чрез добавяне на политика, че пакетът не трябва да има зависимости от пакети извън Haiku? haikuports? (Бих искал, защото такава политика би направила нещата много по-лесни - системата ще може автоматично да разрешава зависимостите на всеки пакет, изтеглен отвсякъде, без да се забърква с допълнителни източници на пакети.)

г-н. waddlesplash обяснява:

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

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

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

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

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

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

Заявки за сливане със статуси на компилация и възможност за изтегляне на компилираните двоични файлове, ако компилацията е успешна (маркирани в зелено)

Компилацията работи в Docker контейнери. GitLab предлага безплатни runners на Linux и мисля, че може да е възможно да включите свои собствени runners (между другото, не виждам как това ще работи за системи като Haiku, за които знам, че нямат Docker или еквивалент, но също така за FreeBSD няма Docker, така че този проблем не е уникален за Haiku).

В идеалния случай приложенията на Haiku могат да бъдат изградени в Docker контейнер за Linux. В тази ситуация асемблирането за Haiku може да бъде въведено в съществуващи конвейери. Има ли кръстосани компилатори? Или трябва да емулирам цялото Haiku в Docker контейнер, използвайки нещо като QEMU/KVM (ако приемем, че ще работи по този начин в Docker)? Между другото, много проекти използват подобни принципи. Например Scribus прави това - вече е достъпно за Haiku. Един ден ще дойде ден, когато мога да изпратя такъв Изтеглете заявки към други проекти, за да добавите поддръжка на Haiku.

Един от разработчиците обяснява:

За други проекти, които желаят сами да създават пакети, се поддържа стандартният метод CMake/CPack. Други системи за изграждане могат да се поддържат чрез директно извикване на програмата за изграждане на пакета, което е добре, ако хората се интересуват от това. Опитът показва: досега нямаше голям интерес, така че haikuporter работеше колкото ни е удобно, но в крайна сметка и двата метода трябва да работят заедно. Трябва да въведем набор от инструменти за кръстосано изграждане на софтуер от Linux или друга сървърна операционна система (Haiku не е проектиран да работи на сървъри).

Аплодирам. Редовните потребители на Linux носят целия този допълнителен товар и допълнителен багаж (сигурност, строг контрол и т.н.), който е необходим за сървърна операционна система, но не и за лична. Така че съм напълно съгласен, че възможността за изграждане на приложения на Haiku на Linux е правилният начин.

Заключение

Пренасянето на POSIX приложения към Haiku е възможно, но може да е по-скъпо от обикновеното възстановяване. Определено щях да се занимавам с това дълго време, ако не беше помощта на хората от канала #haiku в мрежата irc.freenode.net. Но дори и те не винаги виждаха веднага какво не е наред.

Приложенията, написани на Qt, са лесно изключение. Съставих просто демо приложение без никакви проблеми.

Изграждането на пакет за прости приложения също е доста лесно, но само за „традиционно пуснати“, т.е. като архиви с версионен изходен код, предназначени за поддръжка в haikuports. За непрекъснато изграждане (изграждане за всеки комит на промени) с GitHub всичко изглежда не е толкова просто. Тук Haiku изглежда по-скоро като дистрибуция на Linux, отколкото като резултат на Mac, където, когато щракнете върху бутона „Build“ в XCode, получавате пакет .app, готов за вмъкване в изображение на диск .dmg, подготвен за изтегляне на моя уебсайт.
Непрекъснатото изграждане на приложения, базирани на „сървърна“ операционна система, например Linux, най-вероятно ще стане възможно, ако има търсене от разработчиците, но в момента проектът Haiku има други, по-належащи задачи.

Опитайте сами! В края на краищата проектът Haiku предоставя изображения за зареждане от DVD или USB, генерирани ежедневно. За да инсталирате, просто изтеглете изображението и го запишете на флаш устройство, като използвате офорист

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

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

От автор превод: това е петата статия от поредицата за Хайку.

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

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

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