TL;DR: Një fillestar pa parë ndonjëherë Haiku, po përpiqem të portarizoj disa programe nga bota Linux.
Programi im i parë i portarizuar për Haiku, i paketuar në formatin e saj hpkg.
Zbulova Haiku, një sistem operativ të papriturisht të shkëlqyer për PC.
Sot do të mësoj si të portarizoj programe të reja për këtë sistem operativ. Fokusimi kryesor është përshkrimi i përvojës së parë të kalimit në Haiku nga pika e shikimit të një zhvilluesi për Linux. Më vjen keq për gabimet e budallaqeve që kam bërë gjatë procesit, pasi që nga momenti që e kam shkarkuar për herë të parë Haiku, nuk kanë kaluar më shumë se një javë.
Dua të arrij tre qëllime:
- Të portarizoj një aplikacion të thjeshtë CLI.
- Të portarizoj një aplikacion me GUI në Qt.
- Të gjitha pastaj t'i paketoj në formatin hpkg (pasi ende po mendoj për përshtatjen e AppDir dhe AppImage për Haiku...)
Le t'i fillojmë. Në seksionet dhe , si dhe në nga HaikuPorts, gjetëm drejtimin e duhur. Ka edhe një libër online PDF. .
467 faqe — dhe kjo është që nga viti 1997! Të shohësh brenda është frikësuese, por shpresoj për më të mirën. Fjalët inkurajuese të zhvilluesit janë: «e gjatë, pasi BeOS nuk ishte në përputhje me POSIX», por Haiku «në mënyrë të madhe» është kështu tashmë.
Portimi i një aplikacioni të thjeshtë CLI.
Mendimi i parë ishte të portoja aplikacionin , por, siç duket, kjo ka ndodhur tashmë mjaft kohë më parë.
Përpjekja e parë: nuk ka çfarë të shoh.
Çfarë nuk mund të kuptoj është se tashmë — me faktin që vetë sistemi operativ nuk ka as versionin 1.0.
Përpjekja e dytë: duhet ta shkruaj përsëri.
Pra, do të përdor , CLI për të menaxhuar printerin Brother P-Touch 770, mbi të cilin po printoj etiketa.
Po e përdor për të printuar etiketa të ndryshme, dhe ndoshta e keni parë në artikullin e kaluar. Pak më parë shkrova një program të vogël me GUI në Python (dhe duke qenë se është në Gtk+ — do të duhet ta shkruaj përsëri, dhe ky është një rast i mirë për të mësuar më shumë).
Printeri për etiketa Brother P-Touch 770. A do të funksionojë nën Haiku?
Menaxheri i paketave të Haiku njeh libraritë dhe komandat, kështu që nëse marr një mesazh «can’t find libintl» gjatë ekzekutimit konfiguro thjesht ekzekutoj pkgman install devel:libintl dhe paketa e nevojshme do të gjendet. Njësoj si pkgman install cmd:rsync. Po ashtu, etj.
Përveç rasteve kur kjo nuk funksionon:
/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 foundNdoshta udev është shumë linuxor, prandaj nuk ekziston për Haiku. Kjo do të thotë se është e nevojshme të redaktohet kodi burimor që po përpiqem ta kompistoj.
Eh, nuk mund të jetë më lart se kaq, dhe as nuk e di nga të filloj.
Përpjekja e tretë
Do të ishte mirë të kisha tmate për Haiku, atëherë do të lejoja zhvilluesit e Haiku të lidhen me sesionin tim të terminalit — për rastin nëse diçka shkon keq. Udhëzimet janë mjaft të thjeshta:
./autogen.sh
./configure
make
make installDuket mirë, pra pse të mos e provojmë këtë në 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 foundNë këtë hap hap HaikuDepot dhe kërkoj curses.
Diçka mbeti dhe më dha një sugjerim për një kërkesë më të mençur:
/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 foundMë riktheva në HaikuDepot, dhe, sigurisht, gjeta devel:msgpack_c_cpp_devel. Çfarë emrash të çuditshëm?
/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 1Në këtë hap, kuptova se transferimi i programit në Haiku kërkon ndjeshëm më shumë njohuri sesa nevojitet për një rindërtim të thjeshtë.
Bisedova me zhvilluesit miqësorë të Haiku, dhe doli se kishte një defekt në msgpack, dhe pas disa minutash shoh patch, në HaikuPorts. E shoh me sy sesi paketa e korrigjuar (buildslave — makinat virtuale).
Ndërtimi i msgpack të korrigjuar në buildmaster
Ndërkohë dërgoj patch në upstream .
Pesë minuta më pas, msgpack i azhurnuar është tashmë i disponueshëm në 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.Papritur mirë. A thashë unë?!
Kthehem përsëri te detyra fillestare:
/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 1Tani, duket se msgpack nuk është fajtor. Po komentohem IMAXLABEL në tty.c ashtu:
tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|/*IMAXBEL|*/ISTRIP);Rezultati:
osdep-unknown.c: Në funksionin 'osdep_get_cwd':
osdep-unknown.c:32:19: paralajmërim: parameter i papërdorur 'fd' [-Wunused-parameter]
osdep_get_cwd(int fd)
~~~~^~
make: *** Nuk ka rregull për të bërë objektin 'compat/forkpty-unknown.c', që nevojitet nga 'compat/forkpty-unknown.o'. Ndalo.Ja tani, përsëri… Për më tepër:
/Haiku/home/tmate> ./configure | grep -i OPENAT
checking for openat... notregon se ku duhet kërkuar:
/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.Këtu kam publikuar .
Më informuan që ka diçka tjetër në libresolv në Haiku me libnetwork. Duket se duhet të vazhdoj me modifikimin e kodit. Duhet të mendoj...
find . -type f -exec sed -i -e 's|lresolv|lnetwork|g' {} ;Pytja e përjetshme: çfarë po ndodh.
/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 foundE njëjta, por në profil. Kërkova dhe . Nëse shtoj -lssp në disa raste ndihmon, po provoj:
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp"
(...)/Haiku/home/tmate> make
(...)/Haiku/home/tmate> ./tmateWow! Po niset! Por...
[tmate] ssh.tmate.io dështim kërkimi. Po provoj përsëri pas 2 sekondash (dështim të pa-rikuperueshëm në zgjidhjen e emrit)Do të përpiqem ta devoj, :
/Haiku/home/tmate> strace -f ./tmate >log 2>&1"ID i keq i portit" — kjo tashmë është si një vizitë . Ndoshta dikush e di çfarë nuk është në rregull dhe si ta rregulloj? Nëse ka ndonjë gjë, do ta azhurnoj artikullin. Lidhja për .
Portimi i aplikacioneve GUI në Qt.
Po zgjedh një aplikacion të thjeshtë 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!Realistike e thjeshtë. Më pak se një minutë!
Paketimi i aplikacioneve në hpkg duke përdorur haikuporter dhe haikuports.
Nga të filloj? Nuk ka dokumentacion më të thjeshtë, shkoj në kanalin #haiku në irc.freenode.net dhe dëgjoj:
- Ekipa
paketë— një mënyrë e ulët për të krijuar paketa. Në përgjithësi, mjafton PackageInfo, siç përshkruhet në seksionin "Si ta bëjmë atë në një paketë të duhur .hpkg" - Më duhet të bëj diçka
- Mund të përdor (më përjashton, )
Nuk është e qartë se çfarë të bëj. Mendoj se më nevojitet një udhëzues për fillestarë si "Përshëndetje, Botë!", idealisht — një video. Do të ishte mirë gjithashtu të kisha një hyrje të lehtë në HaikuPorter, siç është bërë në GNU hello.
Lexoj të siguiente:
haikuporterështë një mjet për krijimin e projekteve të paketave për Haiku. Ai përdor depozitën HaikuPorts si bazën për të gjitha paketat. Për të krijuar paketa përdoren receta haikuporter.
Shtesë, mësoj se:
Nuk ka nevojë të mbash recetat në depozitën HaikuPorts. Mund të krijosh një depo të re, ta vendosësh atje recetën, dhe pastaj t'i tregosh haikuporter për të.
Ishte pikërisht ajo që më nevojitej — nëse nuk kërkoj një mënyrë për të publikuar paketën. Por kjo është një temë për një post tjetër.
Instalimi i haikuporter dhe 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/ # e bën të ekzekutueshëm nga kudo
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.confShkrimi i një recete
SUMMARY="Demo QtQuick application"
DESCRIPTION="QtQuickApp është një aplikacion demo QtQuick për testimin e portimit dhe paketimit të Haiku"
HOMEPAGE="https://github.com/probonopd/QtQuickApp"
COPYRIGHT="Asnjë"
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
}Ndërtimi i recetës
Po e ruaj skedarin si QtQuickApp-1.0.recipe, pas së cilës e aktivizoj aikuporter -S ./QuickApp-1.0.recipe. Po kontrollohen varësitë për të gjitha paketat në depo , që zë një kohë të caktuar. Po shkoj të pi një kafe.
Po për çfarë arsye duhet të bëhet ky kontroll në makinën time lokale, dhe jo në mënyrë qendrore në server një herë për të gjithë?
Sipas zotit waddlesplash:
Me atë që mund të rishkruaj çdo skedar në depo 😉 Mund ta optimizojmë pak, duke llogaritur informacionin e nevojshëm kur është e nevojshme, sepse ndryshimet e fundit të bëra janë mjaft të rralla.
~/QtQuickApp> haikuporter QtQuickApp-1.0.recipe
Kontrolloni nëse ndonjë informatë e varësisë duhet të përditësohet ...
Duke kërkuar informacion të vjetruar të varësisë ...
Gabim: QtQuickApp nuk u gjet në depoDuket se nuk ka një skedar të zakonshëm recetë, në të cilin është kodi burimor i aplikacionit tuaj. Duhet ta mbani atë në depo në formatin HaikuPorts.
~/QtQuickApp> mv QtQuickApp-1.0.recipe ../haikuports/app-misc/QtQuickApp/
~/QtQuickApp> ../haikuport
~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipeKy fakt e bën ndërtimin më të ndërlikuar. Nuk më pëlqen shumë, por mendoj se është e nevojshme në fund të fundit që të gjithë softueri me kod të hapur të shfaqet në HaikuPorts.
Po marr këtë:
~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe
Kontrolloni nëse ndonjë informatë e varësisë duhet të përditësohet ...
përditësimi i informacionit të varësive të QtQuickApp-1.0
Duke kërkuar informacion të vjetruar të varësisë ...
Gabim: QtQuickApp-1.0.recipe nuk u gjet në pemë.Çfarë është gabim? Pas leximin në irc bëj:
~/QtQuickApp> haikuporter -S QtQuickApp
Kontrolloni nëse ndonjë informacion mbi varësitë duhet të përditësohet ...
përditësimi i informacionit mbi varësitë e QtQuickApp-1.0
Duke kërkuar informacione të vjetruara mbi varësitë ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
/boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Duke shkarkuar: https://github.com/probonopd/QtQuickApp.git ...
--2019-07-14 16:12:44-- https://github.com/probonopd/QtQuickApp.git
Përpunimi i github.com... 140.82.118.3
Lidhja me github.com|140.82.118.3|:443... e lidhur.
Kërkesa HTTP e dërguar, duke pritur përgjigjen... 301 Moved Permanently
Lokacioni: https://github.com/probonopd/QtQuickApp [duke ndjekur]
--2019-07-14 16:12:45-- https://github.com/probonopd/QtQuickApp
Rikuperimi i lidhjes ekzistuese me github.com:443.
Kërkesa HTTP e dërguar, duke pritur përgjigjen... 200 OK
Gjatësia: e pacaktuar [text/html]
Ruajtja në: ‘/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’ ruajtur [90094]
Duke verifikuar checksum-in e QtQuickApp.git
Kujdes: ----- SHABLLONI I KONTROLLIT TE KONTROLLIT -----
Kujdes: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"
Kujdes: -----------------------------
Gabim: Nuk u gjet asnjë checksum në recetë!Shkoi një pyetje interesante. Nëse shtoj një checksum në recetë — a do të përputhet ajo me commit-in e fundit në git për integrimin e vazhdueshëm? (Zhvilluesi konfirmon: «Asgjë nuk do të dalë. Recetat janë krijuar për të qenë relativisht stabile»).
Për të qeshur e shtojnë në recetë:
CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"Akoma nuk më kënaq:
~/QtQuickApp> haikuporter -S QtQuickApp
Duke kontrolluar nëse ndonjë informacion mbi varësitë duhet të përditësohet ...
përditësimi i informacionit mbi varësitë e QtQuickApp-1.0
Duke kërkuar për informacion të vjetruar mbi varësitë ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
/boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------
Kalohet shkarkimi i burimit për QtQuickApp.git
Duke validuar checksum për QtQuickApp.git
Duke zbërthyer burimin e QtQuickApp.git
Gabim: Lloji i arkivës nuk njihet në skedarin /boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.gitÇfarë është ky? Rruga është një depo git, kodi është atje direkt, nuk ka çfarë të zbërthehet. Sipas pikëpamjes time, mjeti duhet të jetë mjaft inteligjent për të mos kërkuar një zbërthim, nëse ka një URL në GitHub.
Mund të funksionojë uri git://
SOURCE_URI="git://github.com/probonopd/QtQuickApp.git"Tani ankohet kështu:
Duke shkarkuar: git://github.com/probonopd/QtQuickApp.git ...
Gabim: Shkarkimi nga burime të pasigurta është i çaktivizuar në haikuports.conf!Hmm, dhe pse gjithçka është kaq e komplikuar, pse nuk mund të «punojë thjesht»? Në fund të fundit, nuk është kaq e rrallë të ndërtohet ndonjë gjë nga GitHub. Disa mjete punojnë menjëherë, pa nevojën për konfigurim, ose ashtu siç e quaj unë «mundim».
Ndoshta do të funksionojë kështu:
SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"Jo, ende vazhdoj të marr këtë mesazh të çuditshëm gabimi dhe bëj,
sed -i -e 's|#ALLOW_UNSAFE_SOURCES|ALLOW_UNSAFE_SOURCES|g' /boot/home/config/settings/haikuports.confPo eci pak më tutje, por pse po më shqetëson (GitHubi nuk është i sigurt!) dhe akoma po përpiqet të nxjerrë diçka.
Sipas :
Po, shkaku ishte dëshira për të kontrolluar integritetin e të dhënave që po merren për ndërtim. Një nga opsionet është verifikimi iChecksum-it të arkivave, por gjithashtu mund të hash edhe skedarë të veçantë, gjë që nuk do të realizohet, sepse zë shumë më tepër kohë. Si pasojë e kësaj është "pasiguria" e git dhe sistemet e tjera të kontrollit të versioneve. Rruga më e mundshme është se kjo do të jetë gjithmonë kështu, pasi të krijosh një arkiv në GitHub është mjaft e lehtë dhe shpesh më e shpejtë. Dhe në të ardhmen, ndoshta, mesazhi për gabimin nuk do të jetë aq i fortë... (ne nuk do të bëjmë më bashkëngjitje të këtij lloji të recetave në HaikuPorts).
~/QtQuickApp> haikuporter -S QtQuickApp
Kontrolloj nëse ndonjë informacion mbi varësitë duhet të përditësohet ...
Duke kërkuar për informacionet mbi varësitë e vjetra ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
/boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Duke shkarkuar: git+https://github.com/probonopd/QtQuickApp.git ...
Kujdes: BURIMET E PA SIGURTA JANË TË KEQJA DHE NUK DUHET TË PËRDOREN NË PRODHIM
Kujdes: JU LUTEM TË KALONI NË NJË DËRGO SUPERSTATIC TË ARKIVIT ME KASHTA SA MË SHPEJT!
Duke klonuar në depo të papërpunuar '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
Duke nxjerrë burimin e QtQuickApp.git
tar: /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0: Nuk mund të hapet: Nuk ekziston një skedë ose direktori e tillë
tar: Gabimi nuk është i rregullueshëm: po dalim tani
Komanda 'git archive HEAD | tar -x -C "/boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0"' ktheu statusin e daljes jo zero 2Sipas zakonit të vjetër, po shkoj të pyes njerëzit e mirë në kanalin #haiku në rrjetin irc.freenode.net. Dhe ku mund të shkoj pa ta? Pas sugjerimit e kuptova se duhet të përdor:
srcGitRev="d0769f53639eaffdcd070bddfb7113c04f2a0de8"
SOURCE_URI="https://github.com/probonopd/QtQuickApp/archive/$srcGitRev.tar.gz"
SOURCE_DIR="QtQuickApp-$srcGitRev"
CHECKSUM_SHA256="db8ab861cfec0ca201e9c7b6c0c9e5e828cb4e9e69d98e3714ce0369ba9d9522"Mirë, tani është e qartë se çfarë bën — shkarkon një arkiv me kodet burimore të një revisi të caktuar. Është marrëzi, sipas pikëpamjes time, dhe nuk është krejtësisht ajo që doja, sidomos — të shkarkoja revisinë më të fundit nga dega kryesore.
Një nga zhvilluesit e shpjegoi këtë kështu:
Ne kemi CI tonë, kështu që çdo gjë që vendoset në repository-n haikuports do të paketohen për të gjithë përdoruesit, dhe nuk duam të rrezikojmë duke mbledhur dhe shpërndarë "të gjitha versionet më të fundit në upstream."
E kuptova! Në çdo rast, këtu është rezultati:
po pret që të aktivizohet paketa e ndërtimit QtQuickApp-1.0-1
po pret që të aktivizohet paketa e ndërtimit QtQuickApp-1.0-1
po pret që të aktivizohet paketa e ndërtimit QtQuickApp-1.0-1
po pret që të aktivizohet paketa e ndërtimit QtQuickApp-1.0-1
po pret që të aktivizohet paketa e ndërtimit QtQuickApp-1.0-1
(...)Kjo përsëritet kështu deri në pafundësi. Duket se është një gabim (ka ndonjë raport? Unë nuk e gjeta).
S haikuporter dhe repository nuk ndjehet se ka një nivel 'vepron thjesht', por, si zhvillues, disa gjëra në punën me Haiku më pëlqejnë. Kryesisht, duket si Open Build Service — një grup mjetesh për ndërtimin e ndërtimeve Linux: jashtëzakonisht i fuqishëm, me një qasje sistemore, por i tepruar për aplikacionin tim të vogël 'hello world'.
Përsëri, sipas mr. waddlesplash:
Përpara gjithçkaje, HaikuPorter është mjaft kërkesor për default (po ashtu ka dhe një mod të analizës, plus një mod të rreptë, që e bën atë edhe më të rreptë!), por vetëm sepse krijon paketa që do të funksionojnë, jo thjesht për të krijuar paketa. Prandaj ai e thekson varësitë e pakonsideruara, bibliotekat e paimportuara siç duhet, versionet e gabuara etj. Qëllimi është të kapë të gjitha problemet, duke përfshirë ato të ardhshme, para se përdoruesi të njoftohet për to (prandaj nuk ishte e mundur të instalohej avrdude, sepse në recetë ishte dhënë një varësi). Bibliotekat nuk janë thjesht paketa të veçanta dhe as versionet e caktuara SO. HaikuPorter ndjek respektimin e të gjitha këtyre në vetë recetat për të shmangur gabimet gjatë ekzekutimit.
Në parim, një nivel i tillë kërkesash është i arsyeshëm kur krijohet një sistem operativ, por më duket i tepruar për një aplikacion "hello world". Kam vendosur të provoj diçka tjetër.
Ndërtoni aplikacione në formatin hpkg, duke përdorur komandën "package create"
Ndoshta, një udhëzim i thjeshtë do të ishte më i përshtatshëm për mua?
mkdir -p apps/
cp QtQuickApp apps/cat > .PackageInfo <<EOF
name QtQuickApp
version 1.0-1
architecture x86_64
summary "Demo QtQuick application"
description "QtQuickApp është një aplikacion demo QtQuick për testimin e portimit dhe paketimit në Haiku"
packager "probono"
vendor "probono"
copyrights "probono"
licenses "MIT"
provides {
QtQuickApp = 1.0-1
}requires {
qt5
}
EOFpackage create -b QtQuickApp.hpkg
package add QtQuickApp.hpkg apps# Shih më poshtë nëse dëshiron që aplikacioni
# të shfaqet gjithashtu në menuPapritur i shpejtë, papritur i thjeshtë, papritur efektiv. Pikërisht ashtu si më pëlqen, mahnitëse!
Instalimi — çfarë dhe ku?
Kam kaluar skedarin QtQuickApp.hpkg në ~/config/packages, duke përdorur menaxherin e skedarëve, pas së cilës QtQuickApp u shfaq magjikisht në ~/config/apps.
Përsëri papritur i shpejtë, i thjeshtë dhe efektiv. Mahnitëse, e pabesueshme!
Por… (ku do të ishim pa to!)
Aplikacioni ende nuk shfaqet në listën e menuve të aplikacioneve dhe në QuickLaunch. Mendoj se tashmë e di se si ta rregulloj. Në menaxherin e skedarëve kaloj QtQuickApp.hpkg nga ~/config/packages në /system/packages.
Jo, ende mungon. Duket se unë (po, gjithashtu udhëzimi) kam kaluar diçka.
Duke shqyrtuar skedën 'Përmbajtja' në HaikuDepot për disa aplikacione të tjera kam parë se kishte skedarë të formatit /data/mimedb/application/x-vnd... çka është edhe më e veçantë, /data/deskbar/menu/Applications/….
E mirë, e çfarë duhet të vendos aty? Le të shohim…
mkdir -p data/deskbar/menu/Applications/
( cd data/deskbar/menu/Applications ; ln -s ../../../../../apps/QtQuickApp . )
paketa shto QtQuickApp.hpkg aplikacioneJam plotësisht i sigurt që ky truk do të funksionojë, por mbeten pyetje: përse është e nevojshme, për çfarë është e nevojshme? Më duket se kjo dëmton përshtypjen e përgjithshme se sistemi është aq i sofistikuar.
Siç shpjegoi z. waddlesplash:
Ndonjëherë ka aplikacione që nevojiten nga aplikacione të tjera, por jo në menu. Për shembull, LegacyPackageInstaller në skenën tuaj, që përpunon arkivat .pkg në formatin BeOS. Do të donim që përdoruesit t'i instalonin, por pranimi i tyre në menu do të shkaktonte konfuzion.
Më duket se ka një zgjidhje më të thjeshtë, për shembull Hidden=true në skedarët .desktop në Linux. Pse të mos e bëjmë informacionin “të fshehur” një burim dhe atribut të sistemit të skedarëve?
Ajo që veçanërisht nuk është e sofistikuar — emri (i një) aplikacioni, që tregon menu, deskbar, është ngjitur ngushtë në rrugë.
z. waddlesplash shpjegon për këtë:
«Deskbar» në këtë rast duhet kuptuar si një term të përgjithshëm (njësoj si «taskbar», që i referohet si aplikacionit Windows, ashtu edhe konceptit të përgjithshëm). Dhe pasi që kjo
deskbar, dhe jo «Deskbar», mund të kuptohet ndryshe.
2 «praktikisht identike» katalogë me aplikacione brenda tyre
Pse ka 2 katalogë me aplikacione, si dhe pse njëri ka aplikacionin tim QtQuickApplication dhe tjetri — jo? (Sepse nuk është vetëm një sistemik, por një tjetër personal, që do të ishte e qartë për mua).
Unë realisht jam ngatërruar dhe mendoj se duhet ta unifikojmë këtë.
koment nga mr. waddlesplash
Në katalogun e Aplikacioneve ka aplikacione që nuk janë të nevojshme në menu. Por situata me menu duhet vërtet të përmirësohet, ta bëjmë atë më të personalizueshme.
Aplikimi, ose kjo nuk do të ndodhë 😉
Mendova: a është vërtet e nevojshme të vendosen aplikacionet në /system/apps, nëse përdoruesit nuk dëshirojnë t'i shohin atje. Ndoshta është më mirë t'i vendosim diku tjetër, ku përdoruesi nuk do të takohet me ta? Ashtu siç është bërë në Mac OS X, ku përmbajtja e paketave .app, e cila nuk duhet të jetë e dukshme për përdoruesin në /Applications, fshihet në thellësitë /System/Library/…«.
Çfarë ndodh me varësitë?
Mendoj se do të ishte mirë të shënohej ndonjë varësi, apo jo? A mund të konsiderohet Qt si një pjesë e detyrueshme e instalimit të Haiku si parazgjedhje? Jo! Qt nuk është instaluar si parazgjedhje. A mund të përcaktojë automatikisht programi i ndërtimit të paketave varësitë duke kontrolluar skedarët ELF? Më thanë se HaikuPorter bëhet me të vërtetë kështu, por paketë jo. E gjithë kjo sepse ai është thjesht një "ndërmëndës pakete", i cili vetë krijon skedarë hpkg.
A duhet ta bëjmë Haiku më të rafinuar duke shtuar një politikë sipas së cilës një paketë nuk duhet të ketë varësi nga paketat që nuk janë pjesë e haikuports? (Мне бы так хотелось, поскольку подобная политика значительно облегчает задачу — система смогла бы автоматически разрешить зависимости каждого пакета, загружаемого откуда угодно, без возни с дополнительными источниками пакетов).
z. waddlesplash shpjegon:
Nuk do të donim ta kufizonim lirinë e zhvilluesve kaq shumë, sepse është e qartë se nëse KompaniaX dëshiron të mbështesë një grup të vetin të softuerit me varësi (dhe rrjedhimisht një depo) — ata e bëjnë këtë në mënyrë të plotë.
Në atë rast, mund të kishte qenë e dobishme të rekomandohej shmangia e paketave të jashtme nga varësitë ndaj ndonjë gjëje që nuk është pjesë e haikuports, duke e paketuar plotësisht gjithçka të nevojshme me aplikacionin. Por, mendoj se kjo është një temë për një artikull të ardhshëm në këtë seri. [Autori po sugjeron AppImage? — shënimi i përkthyesit]
Shtimi i ikonës së aplikacionit
E çfarë ndodh nëse dua të shtoj një nga ikonat e bukura të integruara në burimet e aplikacionit tim të sapo krijuar? Të duket se është një temë e mrekullueshme, kështu që do të jetë tema kryesore për artikullin e ardhshëm.
Si të organizoni ndërtimin e vazhdueshëm të aplikacioneve?
Imagjinoni një projekt si Inkscape (po, e di që nuk është ende në Haiku, por është e lehtë për të treguar). Ata kanë një depo të kodit burimor. https://gitlab.com/inkscape/inkscape.
K çdo herë që dikush regjistron ndryshimet e tij në depo, aktivizohen linjat e ndërtimit, pas së cilës modifikimet testohen automatikisht, ndodhin ndërtimi, aplikacioni paketohet në forma të ndryshme, duke përfshirë AppImage për Linux (një paketë autonome e aplikacionit që mund të ngarkohet për testim lokal, pa marrë parasysh se çfarë mund ose nuk mund të jetë instaluar në sistem). [e dija! — shënimi i përkthyesit]). Po ashtu, çdo gjë ndodh me çdo kërkesë për bashkim dege, kështu që mund të shkarkoni aplikacionin e ndërtuar nga kodi, i propozuar në kërkesën për bashkim, përpara se të bëhet bashkimi.
Kërkesat për bashkëngjitje me statuset e ndërtimit dhe mundësinë për të shkarkuar binarët e ndërtuar në rast të ndërtimit të suksesshëm (të markuara me gjelbër)
Ndërtimi fillon në konteinerat Docker. GitLab ofron runners falas në Linux, për më tepër mendoj se është e mundur të lidhim runners të vetëpërdorur (përveç kësaj, nuk e shoh si do të funksiononte për sisteme si Haiku, të cilat, siç e di, nuk kanë Docker ose ndonjë analog, por për FreeBSD gjithashtu nuk ka Docker, kështu që ky problem nuk është unik për Haiku).
Në një botë ideale ndërtimi i aplikacioneve për Haiku mund të bëhet brenda një konteineri Docker për Linux. Në këtë mënyrë, ndërtimi për Haiku mund të integrohet në konvejerët ekzistues. A ka cross-compilers? Ose duhet të emulojmë gjithë Haiku brenda konteinerit Docker, duke përdorur diçka si QEMU/KVM (në rast se do të funksiononte ashtu brenda Docker)? Përveç kësaj, shumë projekte përdorin parime të ngjashme. Për shembull, Scribus e bën këtë — ai është tashmë në dispozicion për Haiku. Një ditë do të arrij të dërgoj kërkesa për bashkëngjitje në projekte të tjera, për të shtuar mbështetje për Haiku.
Një nga zhvilluesit shpjegon:
Për projekte të tjera që dëshirojnë të krijojnë paketat vetë, mbështetet metoda e zakonshme CMake/CPack. Sistemet e tjera të ndërtimit mund të mbështeten nëse thirren direkt programi i ndërtimit të paketave, gjë që është e mirë, nëse njerëzit janë të interesuar. Eksperienca tregon: deri tani nuk ka pasur interes të veçantë, prandaj haikuporter ka punuar ashtu si na ka përshtatur, por në të vërtetë, të dy metodat duhet të funksionojnë së bashku. Na nevojitet një set mjetesh për ndërtimin e programit nga Linux ose çdo sistem tjetër operativ serveri (Haiku nuk është menduar të funksionojë në servera).
Dua të duartrokas. Përdoruesit e zakonshëm të Linux mbajnë gjithë këtë ngarkesë shtesë dhe bagazhi të shtuar (siguria, kontrolli i rreptë etj.), që është e nevojshme për sistemet operativ server, por jo për ato personale. Prandaj, pajtohem plotësisht që mundësia për të ndërtuar aplikacione për Haiku në Linux është rruga e duhur.
Përfundimi
Portimi i aplikacioneve POSIX në Haiku është i mundur, por mund të kërkojë më shumë përpjekje se rindërtimi i zakonshëm. Në të vërtetë, do të kisha qëndruar me këtë për një kohë të gjatë nëse nuk do të ishte ndihma e njerëzve nga kanali #haiku në rrjetin irc.freenode.net. Por edhe ata nuk e shihnin gjithmonë menjëherë se çfarë ishte e gabuar.
Aplikacionet e shkruara në Qt janë një përjashtim i lehtë. Kam ndërtuar një aplikacion demostrues të thjeshtë pa probleme të veçanta.
Ndërsa ndërtimi i paketës për aplikacione të thjeshta është gjithashtu mjaft i lehtë, por vetëm për ‘ndërtimet tradicionale’, përkatësisht ato që kanë arkiva burimorë me versione, të destinuara për mbështetje në haikuports. Për ndërtimin e vazhdueshëm (ndërtimi për çdo commit në GitHub) gjithçka duket pak më e komplikuar. Këtu Haiku ndjehet më shumë si një shpërndarje Linux, se sa një rezultat në Mаc, ku me një klik të butonit ‘Ndërto’ në XCode merr një paketë .app, e gatshme për t'u futur në imazhin e diskut. .dmg, e përgatitur për ngarkim në faqen time.
Ndërprerja e vazhdueshme e aplikacioneve të bazuara në sistemin operativ "server", për shembull, Linux, ndoshta do të bëhet e mundur nëse ka kërkesë nga zhvilluesit, por aktualisht projekti Haiku ka detyra të tjera më urgjente.
Provo vetë! Projektin Haiku ofron imazhe për ngarkim me DVD ose USB, të krijuara . Për instalimin është e mjaftueshme të shkarkosh imazhin dhe ta regjistrosh në një flash drive me ndihmën e
Keni pyetje? Ju ftojmë në kanalin rusishtfolës të .
Pasqyrë e gabimeve:
Nga përkthimi: ky është artikulli i pestë nga cikli për Haiku.
Lista e artikujve:
Burimi: habr.com
