🥇Dita ime të pestë me Haiku: le të portojmë pak programe

TL;DR: Një fillestar e pa Haiku për herë të parë dhe po përpiqet të portojë disa programe nga bota Linux.

Programi im i parë i portuar për Haiku, i paketuar në formatin e tij hpkg.

Kohët e fundit E kam zbuluar Haiku, një sistem operativ jashtëzakonisht të mirë për PC.
Sot do të mësoj të transferoj programe të reja në këtë sistem operativ. Fokusimi kryesor është përshkrimi i përvojës së parë të kalimit në Haiku nga perspektiva e zhvilluesit për Linux. Më falni për gabimet e thjeshta që do të bëj, pasi që nga hera e parë që ngarkova Haiku, nuk ka kaluar as një javë.

Dua të arrij tri qëllime:

Të portoj një aplikacion të thjeshtë CLI.
Të portoj një aplikacion me GUI në Qt.
Të paketoj ato më pas në formatin hpkg (për shkak se ende po mendoj për adaptimin e AppDir dhe AppImage për Haiku...)

Le të fillojmë. Në seksionet dokumentacioni dhe zhvillimi, si dhe në wiki nga HaikuPorts gjeta drejtimin e duhur. Ka madje një libër online PDF. BeOS: Portimi i aplikacioneve Unix..
467 faqe — dhe kjo qysh nga viti 1997! Të shikosh brenda është paksa frikësuese, por shpresoj për më të mirën. Fjalët përkrahëse të zhvilluesit janë: ‘është e gjatë, sepse BeOS nuk ishte në përputhje me POSIX’, por Haiku ‘në shumë aspekte’ është tashmë e tillë.

Portimi i një aplikacioni të thjeshtë CLI.

Mendimi i parë ishte të portoja aplikacionin avrdude, por, siç duket, kjo tashmë është dhe mund të ekzekutohen nga çdo përdorues, duke lejuar ekzekutimin e këtij imazhi pa nevojën për të drejtat root. Për më tepër, imazhi i migrimit të etcd kryer prej një kohe të gjatë.

Përpjekja e parë: nuk ka asgjë për të parë.

Çka nuk arrij dot të kuptoj është, që tashmë më shumë se 10 vjet aplikacionet portohen për Haiku — duke pasur parasysh se sistemi operativ ende nuk ka një version 1.0.

Përpjekja e dytë: duhet të rishkruaj.

Pra, do të përdor ptouch-770, CLI për menaxhimin e printerit Brother P-Touch 770, në të cilin po printoj etiketa.
Unë printoj etiketa të ndryshme në të dhe ju mund ta keni parë në artikullin e mëparshëm. Pak më parë, shkrova një program të vogël me GUI në Python (pasi që është në Gtk+ — do të duhet ta rishkruaj, dhe kjo është një mundësi e mirë për të mësuar).

Printeri për etiketa Brother P-Touch 770. A do të funksionojë nën Haiku?

Menaxheri i paketave Haiku e njeh bibliotekat dhe komandat, kështu që nëse marr një mesazh ‘can’t find libintl’ gjatë ekzekutimit konfiguro. thjesht nis pkgman install devel:libintl dhe paketa e nevojshme do të gjendet. Njësoj 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 found

Ndoshta udev është shumë linuxian, prandaj nuk ekziston për Haiku. Kjo do të thotë se është e nevojshme të redakohet kodi burimor që po përpiqem ta kompiloj.
Ah, nuk mund të kaloj mbi këtë, dhe nuk 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 terminal - në rast se ndodhin ndonjë problem. Udhëzimet janë mjaft të thjeshta:

.\/autogen.sh
.\/configure
make
make install

Duket 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 found

Në këtë hap hap HaikuDepot dhe kërkoj curses.
Gjeta diçka që më dha një sugjerim për një kërkesë më të saktë:

/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

Përsëri shkova në HaikuDepot, dhe sigurisht që 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 1

Në këtë hap e kuptova se transferimi i programit në Haiku kërkon shumë më tepër njohuri se sa është e nevojshme për një ripërtypje të thjeshtë.
Bisedova me zhvilluesit miqësorë të Haiku, dhe u zbulua që kishte një gabim në msgpack, dhe pas disa minutash shoh patch-in në HaikuPorts. Po shoh për herë të parë se si paketa e korrigjuar po ndërtohet këtu (buildslave - makinat virtuale).

Ndërtimi i msgpack të korrigjuar në buildmaster

Ndërkohë dërgoj patch-in në upstream për të shtuar mbështetje për Haiku në msgpack.

Pesë minuta më vonë, msgpack i përditësuar tashmë është në dispozicion 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.

Për mrekulli të mira. A e thashë unë?!

Kthehem 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 1

Tani, duket se msgpack nuk është faji. Komentoj IMAXLABEL në tty.c e tillë:

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: parametri i pabë përdorur 'fd' [-Wunused-parameter]
 osdep_get_cwd(int fd)
               ~~~~^~
make: *** Asnjë rregull për të bërë objektin 'compat\/forkpty-unknown.c', e nevojshme për 'compat\/forkpty-unknown.o'.  Stop.

Ja, përsëri… Po, për të thënë:

/Haiku/home/tmate> ./configure | grep -i OPENAT
checking for openat... no

mr. waddlesplash tregon se ku të kërkoj:

/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 e kam postuar config.log.

Më shpjeguan që ka diçka tjetër me libresolv në Haiku në libnetwork. Duket se duhet të rregulloj më tej kodin. Duhet të mendoj...

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

Pyetja e përhershme: ç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 found

E njëjta, por në profil. E kërkova në Google dhe gjeta këtë. Nëse shtoj -lssp «ndonjëherë» ndihmon, po mundohem:

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

Wow! Po funksionon! Por…

[tmate] ssh.tmate.io lookup failure. Duke provuar përsëri pas 2 sekondash (dështim të pakthyeshëm në zgjidhjen e emrit)

Do të provoj të ndihmoj, skedari është këtu:

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

«ID porti i keq» - kjo është si një vizitë haiku. Ndoshta dikush di se çfarë është gabim dhe si mund ta rregulloj? Nëse ka diçka, do ta përditësoj artikullin. Lidhja për GitHub.

Portimin e aplikacioneve GUI në Qt.

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!

E vërtetë e lehtë. Më pak se një minutë!

Paketimi i aplikacioneve në hpkg duke përdorur haikuporter dhe haikuports.

Nga ku duhet të filloj? Nuk ka dokumentacion të thjeshtë, shkoj në kanalin #haiku në irc.freenode.net dhe dëgjoj:

Ekipa paketë – një mënyrë me nivel të ulët për të krijuar paketa. Kryesisht, mjafton PackageInfo, siç përshkruhet në seksionin «Bërja e një pakete të rregullt .hpkg»
Më duhet të bëj diçka këtë
Mund të përdorni hpkg-creator (më del gabime, raporti i gabimeve)

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. Po ashtu do të ishte mirë të merrja një hyrje të lehtë në HaikuPorter, siç është bërë në GNU hello.

Po lexoj tërësisht:

haikuporter është një mjet për krijimin e projekteve paketë të përbashkët për Haiku. Ai përdor depozitin HaikuPorts si bazë për të gjitha paketat. Për krijimin e pakorave përdoren receta haikuporter.

Për më tepër, po mësoj se:

Nuk ka nevojë të mbash recetat në depozitën HaikuPorts. Mund të krijosh një depo tjetër, të vendosësh atje recetat dhe pastaj t'ia tregosh haikuporter.

Pikërisht ajo që më nevojitet - përveç nëse nuk kërkoj një mënyrë për të vendosur paketën në mënyrë publike. Por ky është një temë për një postim 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/ # bëje 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.conf

Shkrimi i recetës

SUMMARY="Aplikacion demo QtQuick"
DESCRIPTION="QtQuickApp është një aplikacion demo QtQuick për testimin e kalimit 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 me emrin QtQuickApp-1.0.recipe, pastaj po e filloj haikuporter -S ./QuickApp-1.0.recipe. Po kontrollohen varësitë për të gjitha paketat në depozitën haikuports, që merr pak kohë. Do të shkoj të pi një kafe.

Dhe për cilin shkak ky kontroll duhet bërë në makinën time lokale, dhe jo në mënyrë centralizuar në server një herë për të gjithë?

Sipas zotit waddlesplash:

Pikërisht për faktin se mund të ri-shkruash çdo skedar në depozitë 😉 Mund të optimizohet pak, duke llogaritur informacionin që nevojitet vetëm kur nevojitet, sepse ndryshimet e fundit janë mjaft të rralla.

~QtQuickApp> haikuporter QtQuickApp-1.0.recipe
Kontrollohet nëse ndonjë informacion rreth varësive ka nevojë për tu përditësuar ...
Po kërkohet për informacion të vjetruar të varësive ...
Gabim: QtQuickApp nuk u gjet në depozitë

Duket se nuk ka njëskedari të zakonshëm recetë, që përmban kodin burimor të aplikacionit tuaj. Duhet ta mbash në depozitë në formatin HaikuPorts.

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

Ky kyç e bën montimin më të rëndë. Nuk më pëlqen shumë, por mendoj se është e nevojshme që, në fund, të gjithë softueri me burim të hapur të shkarkohet në HaikuPorts.

Po marr këtë:

~\/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe
Kontrolloj nëse ndonjë informacion për varësitë duhet të azhurnohet ...
        duke azhurnuar informacionet për varësitë e QtQuickApp-1.0
Duke kërkuar informacionet për varësitë e vjetra ...
Gabim: QtQuickApp-1.0.recipe nuk u gjet në pemë.

Çfarë nuk shkon? Pas leximit në irc bëj:

~\/QtQuickApp> haikuporter -S QtQuickApp
Kontrolloj nëse ndonjë informacion për varësitë duhet të azhurnohet ...
        duke azhurnuar informacionet për varësitë e QtQuickApp-1.0
Duke kërkuar informacionet për varësitë e vjetra ...
----------------------------------------------------------------------
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
Duke zgjidhur github.com... 140.82.118.3
Duke u lidhur me github.com|140.82.118.3|:443... e lidhur.
Kërkesa HTTP u dërgua, duke pritur përgjigje... 301 Moved Permanently
Lokacioni: https:\/\/github.com\/probonopd\/QtQuickApp [duke ndjekur]
--2019-07-14 16:12:45--  https:\/\/github.com\/probonopd\/QtQuickApp
Rikthimi i lidhjes ekzistuese me github.com:443.
Kërkesa HTTP u dërgua, duke pritur përgjigje... 200 OK
Gjatësia: e pacaktuar [text\/html]
Duke e ruajtur 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’ e ruajtur [90094]
Duke verifikuar kontrollin e checksum-it të QtQuickApp.git
Kujdes: ----- KONTROLLI I MODELLIT TË KONTROLLIT -----
Kujdes: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"
Kujdes: -----------------------------
Gabim: Nuk u gjet asnjë kontroll në recetë!

Doli një pyetje interesante. Nëse unë shtoj një checksum në recetë - a do të përputhet ajo me commit-in e fundit git për integrimin e vazhdueshëm? (Zhvilluesi e konfirmon: «Nuk do të dalë asgjë. Recetat janë dizajnuar për të qënë relativisht të qëndrueshme»).

Për qejf shtojnë në recetë:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Akoma nuk më pëlqen:

~\/QtQuickApp> haikuporter -S QtQuickApp
Kontrolloj nëse ndonjë informacion për varësitë duhet të azhurnohet ...
        duke azhurnuar informacionet për varësitë e QtQuickApp-1.0
Duke kërkuar informacionet për varësitë e vjetra ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe
----------------------------------------------------------------------
Duke anashkaluar shkarkimin e burimit për QtQuickApp.git
Duke verifikuar kontrollin e checksum-it të QtQuickApp.git
Duke shkarkuar burimin e QtQuickApp.git
Gabim: Lloji i arkivit të panjohur në skedarin \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git

Çfarë është kjo? Pasi është një depo git, kodi është atje direkt, nuk ka asgjë për të shpërbërë. Sipas mendimit tim, instrumenti duhet të jetë mjaft i zgjuar për të mos kërkuar një shpërbues, nëse ka lidhje me GitHub.

Mund të funksionojë uri git:\/

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

Tani ankohesh kështu:

Duke: git://github.com/probonopd/QtQuickApp.git ...
Gabim: Shkarkimi nga burime të pasigurta është ndaluar në haikuports.conf!

Hmm, dhe pse është kaq e komplikuar, pse nuk mund të "punosh thjesht"? Fundja, nuk është e zakonshme të compilosh diçka nga GitHub. Në anën tjetër, janë mjetet që punojnë menjëherë, pa nevojë për konfigurim, ose siç e quaj unë "lodhje".

Ndoshta do të funksionojë kështu:

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

Jo. Akoma po marr këtë gabim të pështirë dhe bëj, siç përshkruhet këtu

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

Po ecni pak më tutje, por pse po më qorton (GitHub nuk është i sigurt!) dhe akoma po përpiqem të nxjerr diçka.

Sipas mr. waddlesplash:

Po, arsyeja është dëshira për të kontrolluar integritetin e të dhënave që po shkarkohen për compilim. Një nga mundësitë është të verifikosh checksum-in e arkivit, por mund të hash edhe skedarët e veçantë, që nuk do të realizohet, pasi merr shumë më tepër kohë. Pasojat e kësaj janë "pasiguria" e git dhe VCS të tjerë. Prandaj, kështu do të jetë gjithmonë, sepse krijimi i një arkivi në GitHub është mjaft i lehtë dhe shpesh herë më i shpejtë. Dhe ndoshta në të ardhmen, mesazhi për gabimin nuk do të jetë kaq alarmant... (ne më nuk bëjmë bashkime të tillë recetash në HaikuPorts).

~/QtQuickApp> haikuporter -S QtQuickApp
Kontrollimi nëse ndonjë informacion në varësi ka nevojë të përditësohet ...
Duke kërkuar për informacion në varësi që janë të 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 ...
Këshillë: BURIMET E PASIGURTA JANË TË KEQIJA DHE NUK DUHET TË PËRDOREN NË PRODHIM
Këshillë: JU LUTEM KALONI NË NJË SHKARKIM STATIK ME CHECKSUM SA MË SHPEJT!
Duke klonuar në depo të zhveshur '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
Duke zbuluar burimin e QtQuickApp.git
tar: /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0: Nuk mund të hapet: Nuk ekziston dosja ose drejtoria
	ar: Gabimi nuk është i rikuperueshëm: duke dalë 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 2

Në mënyrë të zakonshme po kërkoj ndihmën e njerëzve të mirë në kanalin #haiku në rrjetin irc.freenode.net. Dhe ku do të isha pa ta? Pas një sugjerimi 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 kuptoj çfarë bën — shkarkon një arkiv me kodin burim të një revisioni të caktuar. Më duket e çuditshme, dhe nuk është krejtësisht ajo që dëshiroja, veçanërisht — të shkarkohej revisioni më i fundit nga dega master.

Një nga zhvilluesit e shpjegoi këtë kështu:

Ne kemi CI-në tonë, kështu që gjithçka që vendoset në depërtimin haikuports do të paketizohet për të gjithë përdoruesit, dhe ne nuk duam të rrezikojmë duke mbledhur dhe ofruar 'të gjitha versionet e fundit në upstream'.

E kuptova! Në çdo rast, ndodhi kështu:

pritja për aktivizimin e paketës së ndërtimit QtQuickApp-1.0-1
pritja për aktivizimin e paketës së ndërtimit QtQuickApp-1.0-1
pritja për aktivizimin e paketës së ndërtimit QtQuickApp-1.0-1
pritja për aktivizimin e paketës së ndërtimit QtQuickApp-1.0-1
pritja për aktivizimin e paketës së ndërtimit QtQuickApp-1.0-1
(...)

Ajo përsëritet kështu deri në pafundësi. Dukesh se kjo është një gabim (ka një kërkesë? Unë nuk e gjeta).

D haikuporter dhe repository të haikuports nuk ndihet niveli 'thjesht funksionon', por, si zhvillues, disa gjëra në punën me Haiku më pëlqejnë. Kryesisht, kjo ngjan me Shërbimin e Ndërtimit të Hapët — 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 z. waddlesplash:

Vërtet, HaikuPorter është shumë i rreptë në parazgjedhje (plus ka modin lint, si dhe modin e rreptë, duke e bërë atë edhe më të rreptë!), por vetëm sepse ai krijon paketa që do të funksionojnë, e jo thjesht krijojnë paketa. Prandaj ai ankohet për varësitë e pa deklaruara, bibliotekat që nuk janë importuar siç duhet, versione të gabuara, etj. Qëllimi është të kapin të gjitha problemet pa përjashtim, përfshirë ato të ardhshme, para se përdoruesi të dijë për to (prandaj nuk u arrit të instalohet avrdude, sepse në recetë në fakt ishte e specifikuar një varësi). Bibliotekat nuk janë thjesht paketa të veçanta dhe as versione të caktuara SO. HaikuPorter ndjek përputhshmërinë e të gjitha këtyre në vetë recetat, për të shmangur gabimet gjatë ekzekutimit.

Në parim, një nivel i tillë rreptësie është i justifikuar gjatë krijimit të një sistemi operativ, por për mua duket i tepruar për një aplikacion 'hello world'. Kam vendosur të provoj diçka tjetër.

Ndërtimi i aplikacioneve në formatin hpkg, duke përdorur komandën 'package create'

Ndoshta, kjo një udhëzim i thjeshtë do të më përshtatet më mirë?

mkdir -p apps/
cp QtQuickApp apps/cat >  .PackageInfo <<EOF
name QtQuickApp
version 1.0-1
architecture x86_64

summary "Demo aplikacioni QtQuick"
description "QtQuickApp është një aplikacion demo QtQuick për testimin e portimit dhe paketimit të 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ë menynë

Papritur shpejt, papritur thjesht, papritur efektivisht. Ashtu si më pëlqen, mbresëlënëse!

Instalimi - çfarë dhe ku?

E kam zhvendosur skedarin QtQuickApp.hpkg në ~\/config\/packages, duke përdorur menaxherin e skedarëve, pas së cilës QtQuickApp u shfaq magjikisht në ~\/config\/apps.
Sërish papritur shpejt, thjesht dhe efektivisht. Mbresëlënëse, e pabesueshme!

Por... (ku pa ta!)

Aplikacioni ende mungon në listën e menutë të aplikacioneve dhe në QuickLaunch. Mendoj se tashmë e di se si ta rregulloj. Në menaxherin e skedarëve, zhvendos QtQuickApp.hpkg nga ~\/config\/packages në \/system\/packages.

Jo, ende mungon. Duket se unë (dhe udhëzimi) kam harruar diçka.

Duke shqyrtuar kartelën "Përmbajtja" në HaikuDepot për disa aplikacione të tjera, pashë se ka skedarë të tipit /data/mimedb/application/x-vnd... çfarë është edhe më interesante, /data/deskbar/menu/Applications/….

Mirë, dhe çfarë duhet të vendos atje? Le ta shohim...

mkdir -p data\/deskbar\/menu\/Applications\/\n( cd data\/deskbar\/menu\/Applications ; ln -s ..\/..\/..\/..\/apps\/QtQuickApp . )\npackage add QtQuickApp.hpkg apps data

Jam plotësisht i sigurt që ky truk do të funksionojë, por ka pyetje: përse është e nevojshme, për çfarë është e nevojshme? Më duket se kjo e shkatërron përshtypjen e përgjithshme se sistemi është kaq i rafinuar.

Siç e shpjegoi mr. waddlesplash:

Ndonjëherë ka aplikacione që kanë nevojë për aplikacione të tjera, por jo në menu. Për shembull, LegacyPackageInstaller në ekranin tuaj, që trajton arkivat .pkg në formatin BeOS. Dëshirojmë që përdoruesit t'i instalojnë ato, por prania e tyre në menu do të shkaktonte konfuzion.

Më duket se ka një zgjidhje më të thjeshtë, për shembull Hidden=true në skedarë .desktop në Linux. Pse të mos e bëjmë informacionin "të fshehur" një burim dhe atribut të sistemit të skedarëve?

Ajo që nuk është shumë e rafinuar - emri (i një) aplikacioni që shfaq menunë, deskbar, është ngjitur ngushtë në rrugë.

Mr. waddlesplash shpjegon në lidhje me këtë:

"Deskbar" në këtë rast duhet të kuptohet si një term i përgjithshëm (përshtatshëm si për aplikacionin Windows, ashtu edhe për konceptin e përgjithshëm). Prandaj, pasi është deskbar, e jo "Deskbar", mund të kuptohet po ashtu në një mënyrë të ngjashme.

2 "paqera pothuajse identike" me aplikacione në to

Pse ka 2 katalogë me aplikacione dhe gjithashtu pse në një ka QtQuickApplication tim, dhe në tjetrin - nuk ka? (Sepse kjo nuk është një sistem, përkundrazi, një përdorues, që personalisht do të më kishte kuptuar).
Realizoi se kam rënë në konfuzion dhe mendoj se duhet të unifikoj këtë.

koment mr. waddlesplash

Në katalogun Apps ka aplikacione që nuk nevojiten në menu. Megjithatë, situata me menun duhet vërtet përmirësuar, ta bëjmë atë më të personalizueshme.

Aplikimi, ose kjo nuk do të ndodhë 😉

Mendoj: a është e nevojshme të vendosen aplikacionet në /system/apps, nëse përdoruesit nuk janë të interesuar t'i shohin atje. Ndoshta është më mirë t'i vendosim diku tjetër, ku përdoruesi nuk do të ndeshet me ta? Ashtu siç bëhet 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 thellë në /System/Library/…«.

Çfarë ndodh me varësitë?

Mendoj se duhet ndonjëherë të përmenden varësitë, a nuk është? A mund të merret si e domosdoshme që Qt të jetë pjesë e instalimit të Haiku nga default? Jo! Qt nuk është e instaluar nga default. A mund të përcaktohet automatikisht varësitë nga programi i ndërtimit duke kontrolluar skedarët ELF? Më thanë se HaikuPorter vërtet e bën këtë, ndërsa paketë jo. E gjithë kjo sepse ai është thjesht "ndërmarrësi i paketave", i cili vetë krijon skedarë. hpkg.

A duhet ta bëjmë Haiku më të sofistikuar, duke shtuar një politikë sipas së cilës paketa nuk duhet të ketë varësi nga paketat që nuk janë të përfshira në haikuports? (Мне бы так хотелось, поскольку подобная политика значительно облегчает задачу — система смогла бы автоматически разрешить зависимости каждого пакета, загружаемого откуда угодно, без возни с дополнительными источниками пакетов).

mr. waddlesplash shpjegon:

Ne nuk dëshirojmë ta kufizojmë lirinë e zhvilluesve aq shumë, sepse është e qartë që nëse KompaniaX dëshiron të mbështesë një grup të vet të softuerit me varësi (dhe për rrjedhojë një depozitë) — ajo është plotësisht e lirë ta bëjë këtë.

Në këtë rast, mund të ishte e mençur të rekomandojmë që pakot e treta të shmangin varësitë ndaj çfarëdo gjëje që nuk është në 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 ka parasysh AppImage? — shënimi i përkthyesit]

Shtimi i ikonës së aplikacionit

Dhe çfarë ndodh nëse dua të shtoj në burimet e aplikacionit tim të sapo krijuar një nga ikonat e bukura të integruara? Duket se kjo është një temë e habitshme, prandaj do të jetë tema kryesore për artikullin e ardhshëm.

Si të organizojmë ndërtimin e vazhdueshëm të aplikacioneve?

Imagjinoni një projekt të ngjashëm me Inkscape (po, e di që nuk është akoma në Haiku, por është e përshtatshme për ilustruar). Ata kanë një depo të kodit burimor. https://gitlab.com/inkscape/inkscape.
Çdo herë që dikush regjistron ndryshimet e tij në depo, nisë procesi i ndërtimit, pas të cilit ndryshimet testohen automatikisht, ndërtohen, dhe aplikacioni paketizohet në format të ndryshëm, duke përfshirë AppImage për Linux (një paketë autonome aplikacioni që mund të shkarkohet për testimin lokal pavarësisht se çfarë mund ose nuk mund të jetë instaluar në sistem). [e dija! — shënim përkthyes]). Po ashtu ndodh çdo herë që bëhet një kërkesë për bashkim të degëve, kështu që mund të shkarkoni aplikacionin e ndërtuar nga kodi i propozuar në kërkesën për bashkim, para se të bëhet bashkimi.

Kërkesat për bashkim me statuset e ndërtimit dhe mundësinë për të shkarkuar binarët e ndërtuar në rast të një ndërtimi të suksesshëm (e shënuar me gjelbër).

Ndërtimi nis në konteinerë Docker. GitLab ofron runners falas në Linux, dhe mendoj se është e mundur të lidhni runners tuajat (në fakt, nuk e imagjinoj se si do funksiononte kjo për sisteme si Haiku, të cilat, sa di unë, nuk kanë Docker ose një ekuivalent, por që FreeBSD gjithashtu nuk ka Docker, kështu që kjo problematikë nuk është unike për Haiku).

Në kushtet ideale, ndërtimi i aplikacioneve për Haiku mund të realizohet brenda një konteineri Docker për Linux. Në këtë rast, ndërtimi për Haiku mund të integrohet në proceset ekzistuese. A ka cross-compilers? Apo duhet të emulojmë të gjithë Haiku-in brenda konteinerit Docker, duke përdorur diçka si QEMU/KVM (me kusht që të funksionojë kështu brenda Docker-it)? Për më tepër, shumë projekte përdorin parime të ngjashme. Për shembull, Scribus bën kështu — ai është tashmë në dispozicion për Haiku. Një ditë do të vijë koha kur do të mund të dërgoj kështu kërkesat për bashkim në projekte të tjera, për t'i shtuar atyre 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 kërkoni programin e ndërtimit të paketave direkt, që është e mirë nëse njerëzit janë të interesuar për këtë. Eksperienca tregon: deri tani nuk ka pasur interes të veçantë, kështu që haikuporter ka funksionuar ashtu siç na ka lejuar, por, në fund, të dy metodat duhet të punojnë së bashku. Na nevojitet një grup mjetesh për ndërtimin e softuerit në mënyrë ekuivalente nga Linux ose çdo sistem tjetër operativ serverik (Haiku nuk është menduar për të punuar në servera).

Duart të ngelesh në këmbë. Përdoruesit e zakonshëm të Linux po bartin tërë këtë ngarkesë shtesë dhe bagazhin e nevojshëm (siguria, kontrolli i rreptë etj.) për sistemin operativ të serverit, por jo për atë personal. Prandaj, unë jam plotësisht dakord se mundësia për të ndërtuar aplikacione për Haiku në Linux është rruga e duhur.

Përfundim

Portimi i aplikacioneve POSIX në Haiku është i mundshëm, por mund të kërkojë më shumë burime sesa mbi rinevojtja e zakonshme. Sigurisht që do ta lija këtë punë për një kohë të gjatë, nëse nuk do ishte ndihma e njerëzve nga kanali #haiku në rrjetin irc.freenode.net. Por edhe ata nuk e panë gjithmonë menjëherë se çfarë ishte e gabuar.

Aplikacionet e shkruara në Qt janë një përjashtim i lehtë. Unë ndërtova një aplikacion demonstrues të thjeshtë pa ndonjë problem të veçantë.

Ndërtimi i paketave për aplikacione të thjeshta është gjithashtu mjaft i lehtë, por vetëm për ato "të lëshuara në mënyrë tradicionale", dmth. që kanë arkivat e versionuara të kodit burimor, të destinuara për mbështetje në haikuports. Për ndërtimin e vazhdueshëm (ndërtimi për çdo ndryshim) nga GitHub gjithçka duket më e komplikuar. Këtu Haiku ndjehet më shumë si një distro Linux, sesa si një rezultat në Mac, ku me një klik në butonin "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ërtimi i vazhdueshëm i aplikacioneve mbi sistemin operativ "server", për shembull, Linux, shumë mundësi është që të bëhet i mundur nëse do të ketë kërkesë nga zhvilluesit, por për momentin projekti Haiku ka detyra të tjera më urgjente.

Provoja vetë! Sepse projekti Haiku ofron imazhe të ngarkimit nga DVD ose USB, që formohen çdo ditë. Për ta instaluar mjafton të shkarkoni imazhin dhe ta regjistroni në një flash drive duke përdorur Etcher

Keni ndonjë pyetje? Ju ftojmë në kanalin tonë në gjuhën ruse telegram-channel.

Pasqyrë e gabimeve: Si të gjuash veten në këmbë në C dhe C++. Kolleksioni i recetave për Haiku OS

Nga autori përkthimi: kjo është artikulli i pestë nga cikli për Haiku.

Lista e artikujve: I pari I dyti I tretë I katërt

Burimi: habr.com