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

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

ТЛ; ДР: Новајлија је први пут видео Хаику, покушавајући да пренесе неке програме из света Линук-а.

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

Недавно Открио сам Хаику, изненађујуће добар оперативни систем за рачунаре.
Данас ћу научити како да пренесем нове програме на овај оперативни систем. Главни фокус је опис првог искуства преласка на Хаику са становишта Линук програмера. Извињавам се за све глупе грешке које сам направио успут, јер није прошло ни недељу дана откако сам први пут преузео Хаику.

Желим да постигнем три циља:

  • Порт једноставну ЦЛИ апликацију
  • Пренесите апликацију са ГУИ на Кт
  • Затим их упакујте у хпкг формат (пошто још увек размишљам о прилагођавању АппДир-а и АппИмаге-а за Хаику...)

Хајде да почнемо. У секцијама документацију и развој, као и у вики из ХаикуПортс-а сам нашао прави правац. Постоји чак и онлајн ПДФ књига БеОС: Преношење Уник апликације.
467 страница - а ово је из 1997! Страшно је погледати унутра, али надам се најбољем. Речи програмера су охрабрујуће: „требало је доста времена јер БеОС није био компатибилан са ПОСИКС-ом“, али Хаику „већим делом“ је већ такав.

Пренос једноставне ЦЛИ апликације

Прва помисао је била портирање апликације аврдуде, али, како се испоставило, ово је већ направљен давно.

Први покушај: нема шта да се гледа

Оно што већ не могу да разумем је то Апликације су пренете на Хаику више од 10 година - упркос чињеници да сам ОС још није ни верзија 1.0.

Други покушај: потребно је преписати

Зато ћу искористити птоуцх-770, ЦЛИ за контролу Бротхер П-Тоуцх 770 штампача који користим за штампање налепница.
На њему штампам разне етикете, а можда сте то већ видели у претходном чланку. Мало раније, написао сам мали ГУИ програм омотач у Питхон-у (пошто је у Гтк+, мораће да се препише, а ово је добар разлог за учење).

Мој пети дан са Хаикуом: хајде да пренесемо неке програме
Бротхер штампач етикета П-Тоуцх 770. Да ли ће радити са Хаикуом?

Менаџер Хаику пакета зна за библиотеке и команде, па ако добијем поруку „не могу да пронађем либинтл“ приликом покретања 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

Можда је удев превише заснован на Линук-у и стога не постоји за Хаику. Што значи да морам да уредим изворни код који покушавам да компајлирам.
Ех, не можеш да скочиш преко главе, а не знам ни одакле да почнем.

Трећи покушај

Било би лепо имати 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

У овом кораку отварам ХаикуДепот и тражим 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

Опет сам отишао у ХаикуДепот и, наравно, нашао 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/home/tmate> pkgman update
(...)
The following changes will be made:
  in system:
    upgrade package msgpack_c_cpp-3.1.1-1 to 3.2.0-2 from repository HaikuPorts
    upgrade package msgpack_c_cpp_devel-3.1.1-1 to 3.2.0-2 from repository HaikuPorts
Continue? [yes/no] (yes) : y
100% msgpack_c_cpp-3.2.0-2-x86_64.hpkg [13.43 KiB]
(...)
[system] Done.

Неочекивано добро. Сам рекао да?!

Враћам се на првобитни проблем:

/Haiku/home/tmate> make
(...)
In file included from tmux.h:40,
                 from tty.c:32:
compat.h:266: warning: "AT_FDCWD" redefined
 #define AT_FDCWD -100

In file included from tty.c:25:
/boot/system/develop/headers/posix/fcntl.h:62: note: this is the location of the previous definition
 #define AT_FDCWD  (-1)  /* CWD FD for the *at() functions */

tty.c: In function 'tty_init_termios':
tty.c:278:48: error: 'IMAXBEL' undeclared (first use in this function); did you mean 'MAXLABEL'?
  tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|IMAXBEL|ISTRIP);
                                                ^~~~~~~
                                                MAXLABEL
tty.c:278:48: note: each undeclared identifier is reported only once for each function it appears in
Makefile:969: recipe for target 'tty.o' failed
make: *** [tty.o] Error 1

Сада изгледа да мсгпацк није крив. коментаришем IMAXLABEL в tty.c тако:

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.

Овде сам објавио цонфиг.лог.

Објаснили су ми да постоји још нешто у либнетворк-у поред либресолва на Хаикуу. Очигледно, код треба даље да се мења. Треба размислити…

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

„Лош ИД порта“ је већ као визит карта хаику. Можда неко има идеју шта није у реду и како то поправити? Ако је тако, ажурираћу чланак. Линк за ГитХуб.

Портирање ГУИ апликације на Кт.

Ја бирам једноставну КМЛ апликацију.

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

Заиста једноставно. Мање од једног минута!

Паковање апликација у хпкг користећи хаикупортер и хаикупортс.

Од чега да почнем? Не постоји једноставна документација, одем на #хаику канал на ирц.фрееноде.нет и чујем:

  • Тим package - начин на ниском нивоу за креирање пакета. Углавном, ПацкагеИнфо јој је довољан, као што је описано у одељку „Претварање у одговарајући .хпкг пакет“
  • Морам нешто да урадим ово
  • Може користити хпкг-цреатор (сруши ми се, пријављивање грешака)

Није јасно шта да се ради. Претпостављам да ми треба водич за почетнике у стилу Хелло Ворлд, идеално видео. Било би лепо имати и згодан увод у ХаикуПортер, као што се ради у ГНУ хелло.

прочитао сам следеће:

haikuporter је алат за креирање заједничких пакетских пројеката за Хаику. Користи ХаикуПортс спремиште као основу за све пакете. Хаикупортер рецепти се користе за прављење пакета.

Поред тога, сазнајем да:

Нема потребе да чувате рецепте у складишту ХаикуПортс. Можете направити још једно спремиште, ставити рецепте у њега, а затим указати хаикупортеру на њега.

Баш оно што ми треба - ако не тражим начин да јавно објавим пакет. Али ово је тема за други пост.

Инсталирање хаикупортера и хаикупорта

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

Испоставило се да не постоји обична датотека рецепта која садржи изворни код ваше апликације. Морате да га чувате у спремишту у ХаикуПортс формату.

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

Ова чињеница чини монтажу гломазнијом. Не свиђа ми се то посебно, али мислим да је неопходно да би се на крају сав софтвер отвореног кода појавио у ХаикуПортовима.

добијам следеће:

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

Шта није у реду? Након читања ирц-а радим:

~/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!

Појавило се занимљиво питање. Ако додам контролну суму рецепту - да ли ће се подударати са најновијим гит урезивањем за континуирану интеграцију? (Програмер потврђује: „Неће функционисати. Рецепти су дизајнирани да буду релативно стабилни.“)

За забаву, додајте рецепту:

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

Шта он то ради? На крају крајева, ово је гит спремиште, код је већ тамо директно, нема шта да се распакује. Са моје тачке гледишта, алатка би требало да буде довољно паметна да не тражи распакивач ако је изнад ГитХуб УРЛ-а.

Можда ће ури гит:// радити

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!

Хм, зашто је све тако компликовано, зашто не можеш „само да радиш“? На крају крајева, није тако неуобичајено направити нешто од ГитХуб-а. Било да се ради о алатима који раде одмах, без потребе за подешавањем, или како ја то зовем „мучење“.

Можда ће функционисати овако:

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

Идем мало даље, али зашто виче на мене (ГитХуб није безбедан!) и још покушава да нешто распакује.

Према господин. ваддлеспласх:

Па, да, разлог је била жеља да се провери интегритет података примљених на монтажу. Једна од опција је да проверите контролну суму архиве, али можете, наравно, хеширати појединачне фајлове, што неће бити имплементирано, јер потребно је много дуже. Последица овога је „несигурност“ гит-а и других ВЦС-а. Ово ће највероватније увек бити случај, пошто је креирање архиве на ГитХуб-у прилично једноставно и често брже. Па, у будућности, можда порука о грешци неће бити тако блистава... (више не спајамо такве рецепте у ХаикуПортс).

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

По старој навици, питам добре људе на #хаику каналу на мрежи ирц.фрееноде.нет. А где бих ја био без њих? Након наговештаја, схватио сам да треба да користим:

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

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

Један од програмера је то објаснио на следећи начин:

Имамо сопствени ЦИ, тако да ће све што се налази у хаикупортс репозиторијуму бити упаковано за све кориснике, и не желимо да ризикујемо да прикупимо и испоручимо „све у најновијој верзији узводно“.

Примљено к знању! У сваком случају, догодило се следеће:

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 и репозиторијум хаикупортс Нема осећај „само ради“, али као програмеру, неке ствари ми се свиђају у раду са Хаикуом. Углавном је сличан Опен Буилд Сервице-у, скупу алата за прављење Линук верзија: изузетно моћан, са систематским приступом, али претерано за моју малу апликацију „здраво свет“.

Опет, према речима г. ваддлеспласх:

Заиста, ХаикуПортер је прилично стриктан по подразумеваној вредности (плус постоји режим длака као и строги режим који га чини још строжијим!), али само зато што креира пакете који ће функционисати, а не само да креира пакете. Зато се жали на недекларисане зависности, библиотеке које нису правилно увезене, нетачне верзије итд. Циљ је ухватити све проблеме, укључујући и оне будуће, пре него што корисник сазна за то (због тога није било могуће инсталирати аврдуде, јер је зависност заправо наведена у рецепту). Библиотеке нису само појединачни пакети или чак специфичне СО верзије. ХаикуПортер обезбеђује да се све ово поштује у самим рецептима како би се избегле грешке током извршавања.

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

Прављење апликација у хпкг формату помоћу команде „креирај пакет“.

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

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

Неочекивано брзо, неочекивано једноставно, неочекивано ефикасно. Тачно како ми се свиђа, невероватно!

Инсталација - шта и где?

Преместили сте датотеку КтКуицкАпп.хпкг у ~/config/packagesкористећи менаџер датотека, након чега се КтКуицкАпп магично појавио ~/config/apps.
Опет, неочекивано брзо, једноставно и ефикасно. Невероватно, невероватно!

Али... (где бисмо били без њих!)

Апликација још увек недостаје на листи менија апликација и КуицкЛаунцх-у. Мислим да већ знам како да то поправим. У менаџеру датотека померам КтКуицкАпп.хпкг из ~/цонфиг/пацкагес у /систем/пацкагес.

Не, још увек недостаје. Очигледно сам (па и упутства) нешто пропустио.

Погледавши картицу „Садржај“ у ХаикуДепот-у за неке друге апликације, видео сам да постоје датотеке попут /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

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

Како је објаснио г. ваддлеспласх:

Понекад постоје апликације које су потребне другим апликацијама, али нису у менију. На пример, ЛегациПацкагеИнсталлер на снимку екрана, обрађује .пкг архиве у БеОС формату. Волео бих да их корисници инсталирају, али њихово присуство у менију ће довести до забуне.

Из неког разлога ми се чини да постоји једноставније решење, нпр Hidden=true у фајловима .desktop на Линук-у. Зашто не бисте „скривене“ информације учинили ресурсом и атрибутом система датотека?

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

господин. ваддлеспласх објашњава ово:

„Дескбар“ у овом случају треба схватити као неку врсту општег појма (на сличан начин као и „трака задатака“, која се односи и на Виндовс апликацију и на општи концепт). Па, од овога deskbar, а не „Дескбар“, ово се такође може схватити на сличан начин.

Мој пети дан са Хаикуом: хајде да пренесемо неке програме
2 "скоро идентична" директоријума са апликацијама у њима

Зашто постоје 2 директоријума са апликацијама, и зашто је моја КтКуицкАпплицатион у једном, а не у другом? (Уосталом, ово није један системски, већ други кориснички, што би мени лично било разумљиво).
Заиста сам збуњен и мислим да би ово требало да буде уједињено.

коментар мр. ваддлеспласх

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

Апликација, или се то неће десити 😉

Питао сам се: да ли је заиста потребно угостити апликације /system/apps, ако их корисници виде тамо, то је непожељно. Можда би било боље да их поставите на неко друго место где се корисник неће сусрести са њима? Баш као што се то ради у Мац ОС Кс-у, где се налази садржај пакета .app, који не би требало да буде видљив кориснику у /Applications, кријући се у дубинама /Система/Библиотеке/…“`.

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

Мислим да је вредно некако одредити зависности, зар не? Може ли се Кт подразумевано сматрати обавезним делом Хаику инсталације? Јок! Кт није подразумевано инсталиран. Може ли креатор пакета аутоматски открити зависности провером ЕЛФ датотека? Речено ми је да ХаикуПортер то заправо ради, али package Не. То је зато што је то само „програм за прављење пакета“ који сам креира датотеке hpkg.

Да ли Хаику треба учинити софистициранијим додавањем политике да пакет не треба да зависи од пакета ван Хаикуа? haikuports? (Волео бих, јер би таква политика много олакшала ствари – систем би могао аутоматски да реши зависности сваког пакета преузетог са било ког места, без петљања са додатним изворима пакета.)

господин. ваддлеспласх објашњава:

Не бисмо желели толико да ограничавамо слободу програмера, јер је очигледно да ако ЦомпаниКс жели да подржи сопствени сет софтвера са зависностима (а самим тим и репозиторијум), то ће учинити потпуно слободно.

У том случају, можда би било вредно препоручити да пакети треће стране избегавају зависност од свега што није укључено у хаикупортове тако што ће у потпуности упаковати све што је потребно уз апликацију. Али мислим да је ово тема за будући чланак у овој серији. [Да ли аутор иде ка АппИмаге-у? — прибл. преводилац]

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

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

Како организовати континуирану израду апликација?

Замислите пројекат као што је Инксцапе (да, свестан сам да још увек није доступан у Хаику-у, али је згодно да се прикаже на њему). Имају спремиште изворног кода https://gitlab.com/inkscape/inkscape.
Сваки пут када неко унесе своје измене у спремиште, покрећу се цевоводи за изградњу, након чега се промене аутоматски тестирају, граде, а апликација пакује у различите пакете, укључујући АппИмаге за Линук (самостални пакет апликације који се може преузети за локално тестирање без обзира на шта може или не мора бити инсталирано на систему [Знао сам! — прибл. преводилац]). Иста ствар се дешава са сваким захтевом за спајање гране, тако да можете преузети апликацију направљену од кода предложеног у захтеву за спајање пре спајања.

Мој пети дан са Хаикуом: хајде да пренесемо неке програме
Спајање захтева са статусима израде и могућношћу преузимања компајлираних бинарних датотека ако је изградња успешна (означено зеленом бојом)

Изградња ради у Доцкер контејнерима. ГитЛаб нуди бесплатне тркаче на Линук-у и мислим да би било могуће укључити ваше сопствене тркаче (успут, не видим како би ово функционисало за системе као што је Хаику, за који знам да немају Доцкер или еквивалент, али такође за ФрееБСД не постоји Доцкер, тако да овај проблем није јединствен за Хаику).

У идеалном случају, Хаику апликације могу бити направљене унутар Доцкер контејнера за Линук. У овој ситуацији, склоп за хаику се може увести у постојеће цевоводе. Постоје ли унакрсни компајлери? Или да емулирам цео Хаику унутар Доцкер контејнера користећи нешто попут КЕМУ/КВМ (под претпоставком да ће тако функционисати унутар Доцкер-а)? Иначе, многи пројекти користе сличне принципе. На пример, Сцрибус то ради – већ је доступан за Хаику. Једног дана ће доћи дан када ћу моћи да пошаљем такав Повуците захтеве за друге пројекте да бисте додали подршку за Хаику.

Један од програмера објашњава:

За друге пројекте који желе да сами креирају пакете, подржана је обична метода ЦМаке/ЦПацк. Други системи за прављење могу се подржати директним позивањем програма за прављење пакета, што је у реду ако су људи заинтересовани за то. Искуство показује: до сада није било великог интересовања, тако да нам је хаикупортер функционисао како нам је згодно, али, на крају крајева, обе методе би требало да раде заједно. Требало би да уведемо скуп алата за унакрсну изградњу софтвера са Линук-а или било ког другог серверског оперативног система (Хаику није дизајниран да ради на серверима).

Дајем овације. Редовни корисници Линука носе сав овај додатни терет и додатни пртљаг (безбедност, строга контрола итд.) који је неопходан за серверски оперативни систем, али не и за лични. Дакле, потпуно се слажем да је могућност прављења Хаику апликација на Линук-у прави начин.

Закључак

Преношење ПОСИКС апликација на Хаику је могуће, али може бити скупље од типичне реконструкције. Дефинитивно бих се заглавио са овим на дуже време да није било помоћи људи са #хаику канала на мрежи ирц.фрееноде.нет. Али чак ни они нису увек одмах видели шта није у реду.

Апликације написане у Кт-у су лак изузетак. Саставио сам једноставну демо апликацију без икаквих проблема.

Прављење пакета за једноставне апликације је такође прилично лако, али само за оне „традиционално објављене“, тј. поседујући верзионисане архиве изворног кода намењене подршци у хаикупортима. За континуирану градњу (израда за сваку урезивање промена) са ГитХуб-ом, све изгледа није тако једноставно. Овде Хаику више личи на Линук дистрибуцију него као резултат на Мац-у, где када кликнете на дугме „Изгради“ у КСЦоде-у добијате пакет .app, спреман за уметање у слику диска .dmg, припремљен за преузимање на мојој веб страници.
Континуирана израда апликација заснованих на „серверском“ оперативном систему, на пример, Линук-у, највероватније ће постати могућа ако постоји потражња програмера, али у овом тренутку Хаику пројекат има друге, хитније задатке.

Пробајте сами! На крају крајева, Хаику пројекат обезбеђује слике за покретање са ДВД-а или УСБ-а, генерисане дневно. Да бисте инсталирали, само преузмите слику и запишите је на флеш диск помоћу бакрописац

Имате било каквих питања? Позивамо вас на руско говорење телеграм канал.

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

Из аутор превод: ово је пети чланак у серији о хаикуу.

Списак чланака: Прво Други трећи Четврто

Извор: ввв.хабр.цом

Додај коментар