🥇Мојот петти ден со Хаику: ајде да пренесеме некои програми

TL; ДР: Новинар го виде Хаику за прв пат, обидувајќи се да пренесе некои програми од светот на Linux.

Мојата прва пренесена програма на Хаику, спакувана во нејзиниот hpkg формат

Неодамна, Го открив Хаику, изненадувачки добар оперативен систем за компјутери.
Денес ќе научам како да пренесувам нови програми на овој оперативен систем. Главниот фокус е опис на првото искуство на префрлување на Хаику од гледна точка на развивач на Linux. Се извинувам за сите глупави грешки што ги направив на патот, бидејќи не помина ниту една недела откако првпат го преземав Хаику.

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

Поставете едноставна CLI апликација
Префрлете ја апликацијата од GUI во Qt
Потоа пакувајте ги во формат hpkg (бидејќи сè уште размислувам за прилагодување на AppDir и AppImage за Хаику...)

Ајде да почнеме. Во делови документацијата и развој, како и во вики од HaikuPorts ја најдов вистинската насока. Постои дури и онлајн книга PDF BeOS: Пренесување Unix апликација.
467 страници - и ова е од 1997 година! Страшно е да се погледне внатре, но се надевам на најдоброто. Зборовите на развивачот се охрабрувачки: „потребно беше долго време бидејќи BeOS не беше во согласност со POSIX“, но Хаику „во најголем дел“ е веќе таков.

Пренесување едноставна апликација CLI

Првата мисла беше да се пренесе апликацијата аврдуде, но, како што се испостави, ова е веќе направено пред многу време.

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

Она што не можам да го разберам е тоа веќе Апликациите се пренесуваат на Хаику повеќе од 10 години - и покрај фактот што самиот ОС сè уште не е ни верзија 1.0.

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

Па ќе користам точ-770, CLI за контролирање на печатачот Brother P-Touch 770 што го користам за печатење етикети.
На него печатам разни етикети, а можеби веќе сте го виделе во претходната статија. Малку порано, напишав мала програма за обвивка на GUI во Python (бидејќи е во Gtk+, ќе треба да се преработи, и ова е добра причина за учење).

Брат P-Touch 770 печатач за етикети Дали ќе работи со Хаику?

Управувачот со пакети Хаику знае за библиотеки и команди, па ако добијам порака „не можам да најдам 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 и затоа не постои за Хаику. Што значи дека треба да го уредам изворниот код што се обидувам да го компајлирам.
Ех, не можеш да скокнеш преку глава, а јас не знам ни од каде да почнам.

Трет обид

Би било убаво да се има tmate за Хаику, тогаш би им дозволил на развивачите на Хаику да се поврзат со мојата терминална сесија - во случај нешто да тргне наопаку. Инструкциите се прилично едноставни:

./autogen.sh
./configure
make
make install

Изгледа добро, па зошто да не го пробате на хаику?

/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, излезе дека има грешка во msgpack и по неколку минути гледам закрпа во HaikuPorts. Можам со свои очи да видам како е коригиран пакетот оди овде (buildslave - виртуелни машини).

Изградба на коригиран пакет со пораки на buildmaster

Помеѓу времињата испраќам лепенка до спротиводно за да додадете поддршка за Хаику во msgpack.

Пет минути подоцна, ажурираниот пакет со пораки е веќе достапен на Хаику:

/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

г. прскање ви кажува каде да копате:

/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 на Хаику. Очигледно кодот треба дополнително да се уредува. Треба да се размислува…

find . -type f -exec sed -i -e 's|lresolv|lnetwork|g'  {} ;

Вечното прашање: што се случува?

/Haiku/home/tmate> ./configure LDFLAGS="-lbsd"
(...)/Haiku/home/tmate> make
(...)
# Success!# Let's run it:/Haiku/home/tmate> ./tmate
runtime_loader: /boot/system/lib/libssh.so.4.7.2: Could not resolve symbol '__stack_chk_guard'
resolve symbol "__stack_chk_guard" returned: -2147478780
runtime_loader: /boot/system/lib/libssh.so.4.7.2: Troubles relocating: Symbol not found

Истото, само во профил. Гугл и го најде ова. Ако додадете -lssp „Понекогаш“ помага, се обидувам:

/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp"
(...)/Haiku/home/tmate> make
(...)/Haiku/home/tmate> ./tmate

Леле! Почнува! Но…

[tmate] ssh.tmate.io lookup failure. Retrying in 2 seconds (non-recoverable failure in name resolution)

Ќе се обидам да дебагирам поднесете овде:

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

„Bad port ID“ е веќе како визит-картичка хаику. Можеби некој има идеја што не е во ред и како да се поправи? Ако е така, ќе ја ажурирам статијата. Врска до GitHub.

Пренесување на апликацијата GUI во Qt.

Избирам едноставна QML апликација.

/> cd /Haiku/home//Haiku/home> git clone https://github.com/probonopd/QtQuickApp
/Haiku/home/QtQuickApp> qmake .
/Haiku/home/QtQuickApp> make
/Haiku/home/QtQuickApp> ./QtQuickApp # Works!

Навистина едноставно. Помалку од една минута!

Апликации за пакување во hpkg користејќи haikuporter и haikuports.

Со што да почнам? Нема едноставна документација, одам на каналот #haiku на irc.freenode.net и слушам:

Тим package - начин на ниско ниво за креирање пакети. Во најголем дел, PackageInfo е доволно за неа, како што е опишано во делот „Да се направи соодветен .hpkg пакет“
Треба да направам нешто е
Може да се користи hpkg-креатор (ми се урива, известување за грешка)

Не е јасно што да се прави. Претпоставувам дека ми треба водич за почетници во стилот на Hello World, идеално видео. Би било убаво да има и удобен вовед во HaikuPorter, како што се прави во GNU hello.

Го прочитав следново:

haikuporter е алатка за креирање заеднички пакет проекти за Хаику. Го користи складиштето HaikuPorts како основа за сите пакети. Рецептите на Хаикупортер се користат за создавање пакети.

Дополнително, дознавам дека:

Нема потреба да чувате рецепти во складиштето на 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. Зависностите се проверуваат за сите пакети во складиштето хаикупорти, за што е потребно извесно време. Ќе одам да земам кафе.

Зошто оваа проверка треба да се направи на мојата локална машина, а не централно на серверот еднаш за секого?

Според г. прскање со вода:

Со таков што може да ја преработите секоја датотека во складиштето 😉 Можете да го оптимизирате ова малку, пресметувајќи ги потребните информации кога е потребно, бидејќи последните направени промени се прилично ретки.

~/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 не е безбеден!) и сè уште се обидува да отпакува нешто.

Според г. прскање:

Па, да, причината беше желбата да се провери интегритетот на податоците добиени за склопување. Една од опциите е да ја потврдите контролната сума на архивата, но, се разбира, можете да хаширате поединечни датотеки, кои нема да се имплементираат, бидејќи потребно е многу подолго. Последица на ова е „несигурноста“ на 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 и складиште хаикупорти Нема чувство „само работи“, но како развивач, има некои работи што ми се допаѓаат во работата со Хаику. Во најголем дел, тој е сличен на Open Build Service, збир на алатки за градење на Linux builds: исклучително моќен, со систематски пристап, но претерано за мојата мала апликација „hello world“.

Повторно, според г. прскање со вода:

Навистина, HaikuPorter е стандардно доста строг (плус има режим на влакненца, како и строг режим за да биде уште построг!), но само затоа што создава пакети што ќе функционираат, наместо само да создава пакети. Затоа се жали на непријавени зависности, неправилно увезени библиотеки, неточни верзии итн. Целта е да се фатат сите проблеми, вклучително и идните, пред корисникот да знае за тоа (ова е причината зошто не беше можно да се инсталира avrdude, бидејќи зависноста всушност беше наведена во рецептот). Библиотеките не се само поединечни пакети или дури и специфични верзии на SO. HaikuPorter гарантира дека сето ова е забележано во самите рецепти за да се избегнат грешките при извршувањето.

Во принцип, ова ниво на строгост е оправдано при креирање на оперативен систем, но ми се чини непотребно за апликација „здраво свет“. Решив да пробам нешто друго.

Изградба на апликации во формат hpkg со помош на командата „создај пакет“.

Можеби ова Дали едноставните упатства ќе работат подобро за мене?

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

Сосема сум сигурен дека овој трик ќе работи, но остануваат прашањата: зошто е тоа потребно, за што е тоа? Мислам дека ова го уништува целокупниот впечаток дека системот е толку софистициран.

Како што објасни г. прскање со вода:

Понекогаш има апликации што им се потребни на другите апликации, но не се во менито. На пример, LegacyPackageInstaller во вашата слика од екранот, обработувајќи .pkg архиви во BeOS формат. Би сакал корисниците да ги инсталираат, но нивното присуство во менито ќе доведе до забуна.

Поради некоја причина ми се чини дека има поедноставно решение, на пример Hidden=true во датотеки .desktop на Linux. Зошто „скриените“ информации да не се направат ресурс и атрибут на датотечниот систем?

Она што не е особено суптилно е името на (некоја) апликација која го прикажува менито, deskbar, цврсто врзан на патот.

г. Waddlesplash го објаснува ова:

„Deskbar“ во овој случај треба да се сфати како еден вид општ термин (на ист начин како „лента со задачи“, што се однесува и на апликацијата за Windows и на општиот концепт). Па, од ова deskbar, а не „Deskbar“, ова исто така може да се разбере на сличен начин.

2 „речиси идентични“ директориуми со апликации во нив

Зошто има 2 директориуми со апликации, а исто така зошто мојата QtQuickApplication е во едната, но не и во другата? (На крајот на краиштата, ова не е еден системски, туку втор кориснички, што би ми било лично разбирливо).
Навистина сум збунет и мислам дека ова треба да се обедини.

коментар од г. прскање

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

Апликација, или нема да се случи 😉

Се прашував: дали е навистина потребно да се хостираат апликациите /system/apps, доколку корисниците ги видат таму, тоа е непожелно. Можеби би било подобро да ги поставите на друго место каде што корисникот нема да ги сретне? Исто како што е направено во Mac OS X, каде што содржините на пакетите .app, што не треба да биде видливо за корисникот во /Applications, се крие во длабочините на /Систем/Библиотека/…“`.

Што е со зависностите?

Мислам дека вреди некако да се прецизираат зависностите, нели? Дали Qt може стандардно да се смета за задолжителен дел од инсталацијата на Хаику? Не! Qt не е стандардно инсталиран. Може ли производителот на пакети автоматски да открие зависности со проверка на датотеките ELF? Ми кажаа дека HaikuPorter всушност го прави ова, но package бр. Тоа е затоа што тоа е само „градител на пакети“ кој само сам создава датотеки hpkg.

Дали Хаику треба да се направи пософистициран со додавање политика според која пакетот не треба да има зависност од пакети надвор од Хаику? haikuports? (Би сакал, бидејќи таквата политика ќе ги олесни работите многу - системот ќе може автоматски да ги решава зависностите на секој пакет преземен од каде било, без да се меша со дополнителни извори на пакети.)

г. Waddlesplash објаснува:

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

Во тој случај, можеби вреди да се препорача пакетите од трети страни да избегнуваат зависност од сè што не е вклучено во хаикупортите со целосно пакување на сè што е потребно со апликацијата. Но, мислам дека ова е тема за идна статија во оваа серија. [Дали авторот се движи кон AppImage? - прибл. преведувач]

Додавање икона за апликација

Што ако сакам да додадам една од уредните вградени икони во ресурсите на мојата новосоздадена апликација? Излегува дека ова е неверојатна тема, па затоа ќе биде основа за следната статија.

Како да се организираат континуирани градби на апликации?

Замислете проект како Inkscape (да, свесен сум дека сè уште не е достапен во Хаику, но е погодно да се прикаже на него). Тие имаат складиште за изворен код https://gitlab.com/inkscape/inkscape.
Секој пат кога некој ќе ги изврши своите промени во складиштето, се активираат build pipelines, по што промените автоматски се тестираат, се градат и апликацијата се пакува во различни пакети, вклучувајќи го и AppImage за Linux (самостојна апликација пакет што може да се преземе за локално тестирање без оглед на што може или не може да се инсталира на системот [Знаев! - прибл. преведувач]). Истото се случува со секое барање за спојување на гранки, така што можете да ја преземете апликацијата изградена од кодот предложен во барањето за спојување пред да се споите.

Барања за спојување со статуси на градба и можност за преземање на компајлираните бинарни датотеки ако изградбата е успешна (означена со зелено)

Изградбата работи во контејнери на Docker. GitLab нуди бесплатни тркачи на Linux, и мислам дека е можно да се вклучат ваши сопствени тркачи (патем, не гледам како ова би функционирало за системи како Haiku, за кои знам дека немаат Docker или еквивалент, но исто така за FreeBSD нема Docker, така што овој проблем не е единствен само за Хаику).

Идеално, апликациите за Хаику може да се градат во контејнер Docker за Linux. Во оваа ситуација, склопот за Хаику може да се воведе во постоечките цевководи. Дали има вкрстени компајлери? Или треба да го имитирам целото хаику во контејнер Docker користејќи нешто како QEMU/KVM (претпоставувајќи дека така ќе функционира внатре во Docker)? Патем, многу проекти користат слични принципи. На пример, Scribus го прави ова - веќе е достапен за Хаику. Еден ден ќе дојде денот кога ќе можам да испратам како Повлечете ги барањата до други проекти за да додадете поддршка за Хаику.

Еден од програмерите објаснува:

За други проекти кои сакаат сами да креираат пакети, поддржан е редовниот метод CMake/CPack. Други системи за градење може да се поддржат со директно повикување на програмата за изградба на пакетот, што е во ред доколку луѓето се заинтересирани за тоа. Искуството покажува: досега немаше голем интерес, па хаикупортер ни работеше како погодно, но, во крајна линија, двата методи треба да работат заедно. Треба да воведеме сет на алатки за вкрстено градење софтвер од Linux или кој било друг оперативен систем на сервери (Хаику не е дизајниран да работи на сервери).

Упатувам овации. Редовните корисници на Линукс го носат целиот овој дополнителен товар и дополнителен багаж (безбедност, строга контрола итн.) кој е неопходен за оперативен систем на сервер, но не и за личен. Така, јас целосно се согласувам дека можноста да се изградат Хаику апликации на Linux е начин да се оди.

Заклучок

Пренесувањето на апликациите на POSIX на Хаику е можно, но може да биде поскапо од вообичаената обнова. Дефинитивно ќе бев заглавен со ова долго време да не беше помошта од луѓето од каналот #haiku на мрежата irc.freenode.net. Но, дури и тие не секогаш веднаш гледаа што не е во ред.

Апликациите напишани во Qt се лесен исклучок. Составив едноставна демо апликација без никакви проблеми.

Изградбата на пакет за едноставни апликации е исто така доста лесно, но само за оние „традиционално објавените“, т.е. има верзии на архиви на изворен код наменети за поддршка во хаикупортите. За континуирано градење (изградба за секое извршување на промени) со GitHub, се чини дека сè не е толку едноставно. Овде, Хаику се чувствува повеќе како дистрибуција на Linux отколку резултат на Mac, каде што кога ќе кликнете на копчето „Build“ во XCode добивате пакет .app, подготвен да се вметне во слика на дискот .dmg, подготвен за преземање на мојата веб-страница.
Континуираното градење на апликации засновани на оперативен систем „сервер“, на пример, Linux, најверојатно ќе стане возможно доколку има побарувачка од програмерите, но во моментов проектот Хаику има други, поитни задачи.

Пробајте го сами! На крајот на краиштата, проектот Хаику обезбедува слики за подигање од ДВД или USB, генерирани секојдневно. За да инсталирате, само преземете ја сликата и напишете ја на флеш-уред користејќи ја Етчер

Дали имате прашања? Ве покануваме на рускиот јазик телеграмски канал.

Преглед на грешка: Како да си пукате во стапалото во C и C++. Колекција на рецепти за Хаику ОС

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

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

Извор: www.habr.com

Мојот петти ден со Хаику: ајде да пренесеме некои програми