Dita ime e pestë me Haikun: le të portojmë disa programe

Dita ime e pestë me Haikun: le të portojmë disa programe

TL; DR: Një fillestar pa Haikun për herë të parë, duke u përpjekur të portojë disa programe nga bota Linux.

Dita ime e pestë me Haikun: le të portojmë disa programe
Programi im i parë i portuar Haiku, i paketuar në formatin e tij hpkg

Kohët e fundit Zbulova Haiku, një sistem operativ çuditërisht i mirë për PC.
Sot do të mësoj se si të transferoj programe të reja në këtë sistem operativ. Fokusi kryesor është një përshkrim i përvojës së parë të kalimit në Haiku nga këndvështrimi i një zhvilluesi Linux. Kërkoj falje për çdo gabim marrëzi që kam bërë gjatë rrugës, pasi nuk ka kaluar as një javë që kur kam shkarkuar për herë të parë Haiku.

Unë dua të arrij tre qëllime:

  • Portoni një aplikacion të thjeshtë CLI
  • Transferoni një aplikacion nga GUI në Qt
  • Pastaj paketojini ato në formatin hpkg (pasi jam ende duke menduar të adaptoj AppDir dhe AppImage për Haiku...)

Le të fillojmë. Në seksione dokumentacionin и zhvillimi, dhe kështu me radhë wiki nga HaikuPorts gjeta drejtimin e duhur. Ekziston edhe një libër PDF në internet BeOS: Transportimi i një aplikacioni Unix.
467 faqe - dhe kjo është e vitit 1997! Është e frikshme të shikosh brenda, por shpresoj për më të mirën. Fjalët e zhvilluesit janë inkurajuese: "U desh shumë kohë sepse BeOS nuk ishte në përputhje me POSIX", por Haiku "në pjesën më të madhe" tashmë është i tillë.

Transportimi i një aplikacioni të thjeshtë CLI

Mendimi i parë ishte portimi i aplikacionit avrdude, por, siç doli, kjo është tashmë bërë shumë kohë më parë.

Provoni së pari: asgjë për të parë

Ajo që nuk mund ta kuptoj është se tashmë Aplikacionet janë transferuar në Haiku për më shumë se 10 vjet - përkundër faktit se vetë OS nuk është ende versioni 1.0.

Përpjekja e dytë: nevoja për të rishkruar

Kështu që unë do të përdor ptouch-770, CLI për kontrollin e printerit Brother P-Touch 770 që përdor për të printuar etiketa.
Unë shtyp etiketa të ndryshme mbi të, dhe ju mund ta keni parë tashmë në artikullin e mëparshëm. Pak më herët, kam shkruar një program të vogël mbështjellës GUI në Python (meqenëse është në Gtk+, do të duhet të rishkruhet dhe kjo është një arsye e mirë për të mësuar).

Dita ime e pestë me Haikun: le të portojmë disa programe
Printeri i etiketave Brother P-Touch 770. A do të funksionojë me Haiku?

Menaxheri i paketave Haiku di për bibliotekat dhe komandat, kështu që nëse marr një mesazh "nuk mund ta gjej libintl" gjatë ekzekutimit configure - Sapo nis pkgman install devel:libintl dhe do të gjendet paketa e kërkuar. Po kështu pkgman install cmd:rsync. Epo, 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ë i bazuar në Linux dhe për këtë arsye nuk ekziston për Haiku. Që do të thotë se duhet të modifikoj kodin burimor që po përpiqem të përpiloj.
Eh, ju nuk mund të hidheni mbi kokën tuaj, dhe unë nuk di as nga të filloj.

Prova e tretë

Do të ishte mirë të kishim tmate për Haiku, atëherë unë do t'i lejoja zhvilluesit e Haiku të lidhen me sesionin tim të terminalit - në rast se diçka shkon keq. Udhëzimet janë mjaft të thjeshta:

./autogen.sh
./configure
make
make install

Duket mirë, kështu që pse të mos e provoni 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.
U gjet diçka, e cila më dha një sugjerim për një pyetje më kompetente:

/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, natyrisht, gjeta devel:msgpack_c_cpp_devel. Cilët janë këta emra 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, kuptova se transferimi i një programi në Haiku kërkon shumë më tepër njohuri sesa nevojitet për një rindërtim të thjeshtë.
Kam biseduar me zhvilluesit miqësorë të Haiku, doli se ka një gabim në msgpack dhe pas disa minutash shoh një patch në HaikuPorts. Unë mund të shoh me sytë e mi se si paketa e korrigjuar duke shkuar këtu (buildslave - makina virtuale).

Dita ime e pestë me Haikun: le të portojmë disa programe
Ndërtimi i paketës së korrigjuar të mesazheve në buildmaster

Në mes herë dërgoj një patch në rrjedhën e sipërme për të shtuar mbështetjen e Haiku në msgpack.

Pesë minuta më vonë, paketa e përditësuar e mesazheve është tashmë e disponueshme 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ë. E thashë këtë?!

I kthehem problemit origjinal:

/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 sikur msgpack nuk është fajtor. po komentoj IMAXLABEL в tty.c si më poshtë:

tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|/*IMAXBEL|*/ISTRIP);

Rezultati:

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.

Epo, ja ku shkojmë përsëri... Meqë ra fjala:

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

Zoti. spërkatje ju tregon se ku të gërmoni:

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

Ata më shpjeguan se ka diçka tjetër në libnetwork përveç libresolv në Haiku. Me sa duket kodi duhet të modifikohet më tej. Duhet menduar…

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

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

E njëjta gjë, vetëm në profil. Google dhe e gjeti këtë. Nëse shtoni -lssp "nganjëherë" ndihmon, përpiqem:

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

Uau! Po fillon! Por…

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

Do të përpiqem të korrigjoj gabimet dosje këtu:

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

"Bad port ID" është tashmë si një kartëvizitë haiku. Ndoshta dikush ka një ide se çfarë nuk shkon dhe si ta rregullojmë atë? Nëse po, do ta përditësoj artikullin. Lidh me GitHub.

Transferimi i aplikacionit GUI në Qt.

Unë 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!

Vërtetë e thjeshtë. Më pak se një minutë!

Aplikacionet e paketimit në hpkg duke përdorur haikuporter dhe haikuports.

Me çfarë duhet të filloj? Nuk ka asnjë dokumentacion të thjeshtë, shkoj në kanalin #haiku në irc.freenode.net dhe dëgjoj:

  • Ekip package - një mënyrë e nivelit të ulët për të krijuar paketa. Në pjesën më të madhe, PackageInfo është e mjaftueshme për të, siç përshkruhet në seksionin "Të bëjmë atë në një paketë të duhur .hpkg"
  • Më duhet të bëj diçka kjo
  • Mund të përdorë hpkg-krijues (për mua rrëzohet, raportimi i gabimeve)

Nuk është e qartë se çfarë duhet bërë. Mendoj se më duhet një udhëzues fillestar në stilin Hello World, në mënyrë ideale një video. Do të ishte mirë të kishim gjithashtu një prezantim të përshtatshëm për HaikuPorter, siç bëhet në GNU hello.

Unë po lexoj sa vijon:

haikuporter është një mjet për krijimin e projekteve të paketave të përbashkëta për Haiku. Ai përdor depon e HaikuPorts si bazë për të gjitha paketat. Recetat Haikuporter përdoren për të krijuar paketa.

Për më tepër, zbuloj se:

Nuk ka nevojë të ruani recetat në hapësirën ruajtëse të HaikuPorts. Mund të bëni një depo tjetër, t'i vendosni recetat në të dhe më pas t'i drejtoni haikuporter.

Vetëm ajo që më nevojitet - nëse nuk kërkoj një mënyrë për ta lëshuar publikisht paketën. Por kjo ë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/ # 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

Shkrimi i një recete

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
}

Mbledhja e recetës

Unë e ruaj skedarin nën emrin QtQuickApp-1.0.recipe, pas së cilës nis aikuporter -S ./QuickApp-1.0.recipe. Vartësitë kontrollohen për të gjitha paketat në depo haikuports, e cila kërkon pak kohë. Do shkoj te pi nje kafe.

Pse në tokë duhet të bëhet ky kontroll në makinën time lokale, dhe jo në qendër në server një herë për të gjithë?

Sipas z. spërkatje me valë:

Me të tilla që mund të rishkruash çdo skedar në depo 😉 Mund ta optimizosh pak këtë, duke llogaritur informacionin e nevojshëm kur të nevojitet, sepse ndryshimet e fundit të bëra janë mjaft të rralla.

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

Rezulton se nuk ekziston diçka e tillë si një skedar i rregullt recetë që përmban kodin burimor të aplikacionit tuaj. Ju duhet ta mbani atë në një depo në formatin HaikuPorts.

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

Ky fakt e bën montimin më të rëndë. Nuk më pëlqen veçanërisht, por mendoj se është e nevojshme që përfundimisht të gjithë softuerët me burim të hapur të shfaqen në HaikuPorts.

Unë marr sa vijon:

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

Çfarë nuk shkon? Pasi lexoj irc, bëj:

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

Një pyetje interesante ka lindur. Nëse shtoj një shumë kontrolli në recetë - a do të përputhet me angazhimin më të fundit të git për integrim të vazhdueshëm? (Zhvilluesi konfirmon: "Nuk do të funksionojë. Recetat janë krijuar për të qenë relativisht të qëndrueshme.")

Për argëtim, shtoni në recetë:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Ende i pa kënaqur:

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

Çfarë po bën ai? Në fund të fundit, ky është një depo git, kodi është tashmë atje drejtpërdrejt, nuk ka asgjë për të shpaketuar. Nga këndvështrimi im, mjeti duhet të jetë mjaft i zgjuar për të mos kërkuar një shpaketues nëse është mbi url-në e GitHub.

Ndoshta uri git:// do të funksionojë

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

Tani ankohet kështu:

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

Hmm, pse është gjithçka kaq e ndërlikuar, pse nuk mund të "punoni thjesht"? Në fund të fundit, nuk është aq e pazakontë të ndërtosh diçka nga GitHub. Qoftë vegla që funksionojnë menjëherë, pa nevojën e konfigurimit, apo siç e quaj unë "shumë".

Ndoshta do të funksionojë kështu:

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

Jo. Unë ende e marr këtë gabim të çuditshëm dhe e bëj, siç përshkruhet këtu

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

Unë po shkoj pak më tej, por pse po më bërtet (GitHub nuk është i sigurt!) dhe ende përpiqet të shpaketojë diçka.

Sipas Zoti. spërkatje:

Epo, po, arsyeja ishte dëshira për të kontrolluar integritetin e të dhënave të marra për montim. Një nga opsionet është të verifikoni kontrollin e arkivit, por sigurisht që mund të hash skedarët individualë, të cilët nuk do të zbatohen, sepse zgjat shumë më tepër. Pasoja e kësaj është "pasiguria" e git dhe QV-ve të tjera. Kjo ka shumë të ngjarë të jetë gjithmonë rasti, pasi krijimi i një arkivi në GitHub është mjaft i lehtë dhe shpesh më i shpejtë. Epo, në të ardhmen, ndoshta mesazhi i gabimit nuk do të jetë aq i ndezur... (ne nuk bashkojmë më receta të tilla në HaikuPorts).

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

Nga zakoni i vjetër, shkoj të pyes njerëz të mirë në kanalin #haiku në rrjetin irc.freenode.net. Dhe ku do të isha pa to? Pas sugjerimit, 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ë, u bë e qartë se çfarë bën - ai shkarkon një arkiv me kodin burimor të një rishikimi të caktuar. Është marrëzi, nga këndvështrimi im, dhe jo saktësisht ajo që doja, domethënë, të shkarkoja rishikimin më të fundit nga dega master.

Një nga zhvilluesit e shpjegoi këtë në këtë mënyrë:

Ne kemi CI-në tonë, kështu që gjithçka që vendoset në depon e haikuports do të paketohet për të gjithë përdoruesit dhe ne nuk duam të rrezikojmë të mbledhim dhe shpërndajmë "gjithçka në versionin më të fundit në rrjedhën e sipërme".

Kuptohet! Në çdo rast, kjo është ajo që ndodhi:

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
(...)

Ai e përsërit këtë pafundësisht. Me sa duket ky është një gabim (a ka ndonjë aplikacion? Nuk e gjeta).

С haikuporter dhe depoja haikuports Nuk ka një ndjenjë "thjesht punon", por si zhvillues, ka disa gjëra që më pëlqejnë në punën me Haikun. Në pjesën më të madhe, është i ngjashëm me Open Build Service, një grup mjetesh për ndërtimin e ndërtimeve Linux: jashtëzakonisht i fuqishëm, me një qasje sistematike, por i tepërt për aplikacionin tim të vogël "hello world".

Përsëri, sipas z. spërkatje me valë:

Në të vërtetë, HaikuPorter është mjaft i rreptë si parazgjedhje (plus ka një modalitet lint si dhe një mënyrë strikte për ta bërë atë edhe më të rreptë!), por vetëm sepse krijon paketa që do të funksionojnë, në vend që thjesht të krijojë paketa. Kjo është arsyeja pse ai ankohet për varësi të padeklaruara, biblioteka të mos importuara siç duhet, versione të pasakta, etj. Qëllimi është të kapni të gjitha problemet, përfshirë ato të ardhshme, përpara se përdoruesi të dijë për të (kjo është arsyeja pse nuk ishte e mundur të instalohej avrdude, sepse varësia ishte specifikuar në të vërtetë në recetë). Bibliotekat nuk janë vetëm paketa individuale apo edhe versione specifike SO. HaikuPorter siguron që e gjithë kjo të respektohet në vetë recetat për të shmangur gabimet gjatë ekzekutimit.

Në parim, ky nivel ashpërsie justifikohet kur krijoni një sistem operativ, por më duket i panevojshëm për një aplikacion "hello world". Vendosa të provoj diçka tjetër.

Ndërtimi i aplikacioneve në formatin hpkg duke përdorur komandën "krijoni paketën".

Ndoshta, kjo A do të funksionojnë më mirë udhëzimet e thjeshta 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 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

Befasisht i shpejtë, papritur i thjeshtë, papritur efektiv. Pikërisht sa më pëlqen, e mahnitshme!

Instalimi - çfarë dhe ku?

Zhvendos skedarin QtQuickApp.hpkg te ~/config/packagesduke përdorur një menaxher skedari, pas së cilës QtQuickApp u shfaq në mënyrë magjike ~/config/apps.
Përsëri, papritur e shpejtë, e thjeshtë dhe efektive. E mahnitshme, e pabesueshme!

Por... (ku do të ishim pa to!)

Aplikacioni mungon ende në listën e menysë së aplikacioneve dhe QuickLaunch. Unë mendoj se tashmë e di se si ta rregulloj atë. Në menaxherin e skedarëve unë lëviz QtQuickApp.hpkg nga ~/config/packages në /system/packages.

Jo, ende mungon. Me sa duket, unë (mirë, dhe udhëzimet) humba diçka.

Pasi pashë skedën "Përmbajtja" në HaikuDepot për disa aplikacione të tjera, pashë që ka skedarë si p.sh. /data/mimedb/application/x-vnd... ajo që është edhe më e shquar është /data/deskbar/menu/Applications/….

Epo, çfarë duhet të vendos atje? Eja...

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

Jam shumë i sigurt se ky truk do të funksionojë, por pyetjet mbeten: pse është e nevojshme kjo, për çfarë është? Mendoj se kjo prish përshtypjen e përgjithshme se sistemi është kaq i sofistikuar.

Siç shpjegohet nga z. spërkatje me valë:

Ndonjëherë ka aplikacione që u duhen aplikacioneve të tjera, por nuk janë në meny. Për shembull, LegacyPackageInstaller në pamjen tuaj të ekranit, duke përpunuar arkivat .pkg në formatin BeOS. Do të doja që përdoruesit t'i instalonin ato, por prania e tyre në meny do të çojë në konfuzion.

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

Ajo që nuk është veçanërisht delikate është emri i (disa) aplikacionit që tregon menunë, deskbar, i lidhur fort gjatë rrugës.

Zoti. waddlesplash shpjegon këtë:

"Deskbar" në këtë rast duhet të kuptohet si një lloj termi i përgjithshëm (në të njëjtën mënyrë si "Taskbar", i cili i referohet si aplikacionit Windows ashtu edhe konceptit të përgjithshëm). Epo, që nga kjo deskbar, jo "Deskbar", kjo gjithashtu mund të kuptohet në mënyrë të ngjashme.

Dita ime e pestë me Haikun: le të portojmë disa programe
2 drejtori "pothuajse identike" me aplikacione në to

Pse ka 2 drejtori me aplikacione, dhe gjithashtu pse është QtQuickApplication im në njërën, por jo në tjetrën? (Në fund të fundit, ky nuk është një sistem, por një përdorues i dytë, gjë që do të ishte e kuptueshme për mua personalisht).
Jam vërtet konfuz dhe mendoj se kjo duhet të unifikohet.

koment nga z. spërkatje

Katalogu i aplikacioneve përmban aplikacione që nuk nevojiten në meny. Por situata me menunë vërtet duhet të përmirësohet, për ta bërë atë më të personalizueshme.

Aplikim, ose nuk do të ndodhë 😉

Pyesja veten: a është vërtet e nevojshme të priten aplikacionet /system/apps, nëse përdoruesit i shohin atje, është e padëshirueshme. Ndoshta do të ishte më mirë t'i vendosni ato në një vend tjetër ku përdoruesi nuk do t'i takojë? 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, duke u fshehur në thellësitë e /System/Library/…“`.

Po në lidhje me varësitë?

Mendoj se ia vlen të specifikohen disi varësitë, apo jo? A mund të konsiderohet Qt një pjesë e detyrueshme e instalimit të Haiku si parazgjedhje? Jo! Qt nuk është i instaluar si parazgjedhje. A mundet një ndërtues paketash të zbulojë automatikisht varësitë duke kontrolluar skedarët ELF? Më thanë që HaikuPorter e bën këtë në të vërtetë, por package Nr. Kjo për shkak se është thjesht një "ndërtues i paketave" që thjesht krijon skedarë vetë hpkg.

A duhet bërë Haiku më i sofistikuar duke shtuar një politikë që një paketë nuk duhet të ketë varësi nga paketat jashtë Haikut? haikuports? (Do të doja, sepse një politikë e tillë do t'i bënte gjërat shumë më të lehta - sistemi do të ishte në gjendje të zgjidhte automatikisht varësitë e çdo pakete të shkarkuar nga kudo, pa ngatërruar me burime shtesë të paketave.)

Zoti. waddlesplash shpjegon:

Ne nuk do të donim të kufizonim aq shumë lirinë e zhvilluesve, sepse është e qartë se nëse CompanyX dëshiron të mbështesë grupin e vet të softuerit me varësi (dhe për rrjedhojë një depo), do ta bëjë këtë plotësisht lirisht.

Në atë rast, mund të jetë me vlerë të rekomandohet që paketat e palëve të treta të shmangin varësinë nga çdo gjë që nuk përfshihet në haikuports, duke paketuar plotësisht gjithçka që nevojitet me aplikacionin. Por unë mendoj se kjo është një temë për një artikull të ardhshëm në këtë seri. [A po shkon autori drejt AppImage? - përafërsisht. përkthyes]

Shtimi i një ikone aplikacioni

Po sikur të dua të shtoj një nga ikonat e rregullta të integruara në burimet e aplikacionit tim të sapokrijuar? Rezulton se kjo është një temë e mahnitshme, kështu që do të jetë baza për artikullin tjetër.

Si të organizoni ndërtime të vazhdueshme të aplikacioneve?

Imagjinoni një projekt si Inkscape (po, jam i vetëdijshëm që nuk është ende i disponueshëm në Haiku, por është i përshtatshëm për t'u shfaqur në të). Ata kanë një depo të kodit burimor https://gitlab.com/inkscape/inkscape.
Sa herë që dikush kryen ndryshimet e tij në depo, lansohen tubacionet e ndërtimit, pas së cilës ndryshimet testohen, ndërtohen automatikisht dhe aplikacioni paketohet në paketa të ndryshme, duke përfshirë AppImage për Linux (një paketë aplikacioni e pavarur që mund të shkarkohet për testim lokal pavarësisht çfarë mund ose nuk mund të instalohet në sistem [E dija! - përafërsisht. përkthyes]). E njëjta gjë ndodh me çdo 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 përpara se të bashkoheni.

Dita ime e pestë me Haikun: le të portojmë disa programe
Bashkoni kërkesat me statuset e ndërtimit dhe aftësinë për të shkarkuar binarët e përpiluar nëse ndërtimi është i suksesshëm (shënuar me jeshile)

Ndërtimi funksionon në kontejnerët Docker. GitLab ofron vrapues falas në Linux dhe mendoj se mund të jetë e mundur të përfshihen vrapuesit tuaj (nga rruga, nuk e kuptoj se si do të funksiononte kjo për sisteme si Haiku, të cilat e di që nuk kanë Docker ose ekuivalent, por gjithashtu për FreeBSD nuk ka Docker, kështu që ky problem nuk është unik për Haikun).

Në mënyrë ideale, aplikacionet Haiku mund të ndërtohen brenda një kontejneri Docker për Linux. Në këtë situatë, montimi për Haiku mund të futet në tubacionet ekzistuese. A ka përpilues të kryqëzuar? Apo duhet të imitoj të gjithë Haikun brenda një kontejneri Docker duke përdorur diçka si QEMU/KVM (duke supozuar se do të funksionojë kështu brenda Docker)? Nga rruga, shumë projekte përdorin parime të ngjashme. Për shembull, Scribus e bën këtë - është tashmë i disponueshëm për Haiku. Një ditë do të vijë dita kur mund të dërgoj i tillë Tërhiq kërkesat për projekte të tjera për të shtuar mbështetjen e Haiku.

Një nga zhvilluesit shpjegon:

Për projektet e tjera që dëshirojnë të krijojnë vetë paketa, mbështetet metoda e rregullt CMake/CPack. Sisteme të tjera ndërtimi mund të mbështeten duke telefonuar drejtpërdrejt programin e ndërtimit të paketës, gjë që është mirë nëse njerëzit janë të interesuar për të. Përvoja tregon: deri më tani nuk ka pasur shumë interes, kështu që haikuporter ka punuar sa më lehtë për ne, por, në fund të fundit, të dyja metodat duhet të funksionojnë së bashku. Ne duhet të prezantojmë një sërë mjetesh për ndër-ndërtimin e softuerëve nga Linux ose ndonjë sistem tjetër operativ serveri (Haiku nuk është krijuar për t'u ekzekutuar në serverë).

Unë bëj një ovacion në këmbë. Përdoruesit e rregullt të Linux-it mbajnë të gjithë këtë ngarkesë shtesë dhe bagazh shtesë (siguri, kontroll të rreptë, etj.) që janë të nevojshme për një sistem operativ serveri, por jo për atë personal. Kështu që jam plotësisht dakord që të jesh në gjendje të ndërtosh aplikacione Haiku në Linux është mënyra për të shkuar.

Përfundim

Bartja e aplikacioneve POSIX në Haiku është e mundur, por mund të jetë më e shtrenjtë se një rindërtim tipik. Patjetër që do të mbërthehesha 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 jo gjithmonë e panë menjëherë se çfarë nuk shkonte.

Aplikacionet e shkruara në Qt janë një përjashtim i lehtë. Unë bashkova një aplikacion të thjeshtë demo pa asnjë problem.

Ndërtimi i një pakete për aplikacione të thjeshta është gjithashtu mjaft i lehtë, por vetëm për ato "të lëshuara tradicionalisht", d.m.th. duke pasur arkiva të kodit burimor të versionuar të destinuara për mbështetje në haikuports. Për një ndërtim të vazhdueshëm (ndërtim për çdo kryerje ndryshimesh) me GitHub, gjithçka duket se nuk është aq e thjeshtë. Këtu Haiku ndihet më shumë si një shpërndarje Linux sesa rezultati në një Mac, ku kur klikoni butonin "Build" në XCode ju merrni një paketë .app, gati për t'u futur në një imazh të diskut .dmg, përgatitur për shkarkim në faqen time të internetit.
Ndërtimi i vazhdueshëm i aplikacioneve të bazuara në një sistem operativ "server", për shembull, Linux, ka shumë të ngjarë të bëhet i mundur nëse ka kërkesë nga zhvilluesit, por për momentin projekti Haiku ka detyra të tjera, më të ngutshme.

Provojeni vetë! Në fund të fundit, projekti Haiku ofron imazhe për nisje nga DVD ose USB, të krijuara i përditshëm. Për ta instaluar, thjesht shkarkoni imazhin dhe shkruajeni atë në një flash drive duke përdorur gdhendës

A keni ndonjë pyetje? Ju ftojmë në rusisht-folëse kanali telegram.

Pasqyrë e gabimit: Si të qëlloni veten në këmbë në C dhe C++. Koleksioni i recetave të Haiku OS

Nga autori përkthimi: ky është artikulli i pestë i serisë për Haikun.

Lista e artikujve: Первая Dytë Третья i katërt

Burimi: www.habr.com

Shto një koment