TL; DR: Un începător a văzut Haiku pentru prima dată, încercând să port unele programe din lumea Linux.
Primul meu program portat Haiku, ambalat în formatul său hpkg
Am descoperit Haiku, un sistem de operare surprinzător de bun pentru computere.
Astăzi voi învăța cum să port programe noi pe acest sistem de operare. Accentul principal este o descriere a primei experiențe de trecere la Haiku din punctul de vedere al unui dezvoltator Linux. Îmi cer scuze pentru eventualele greșeli stupide pe care le-am făcut pe parcurs, deoarece nu a trecut nici măcar o săptămână de când am descărcat prima dată Haiku.
Vreau să ating trei obiective:
- Portați o aplicație CLI simplă
- Porta o aplicație de la GUI la Qt
- Apoi ambalați-le în format hpkg (din moment ce încă mă gândesc să adaptez AppDir și AppImage pentru Haiku...)
Să începem. În secțiuni и precum și de la HaikuPorts am găsit direcția corectă. Există chiar și o carte PDF online .
467 de pagini - și asta din 1997! E înfricoșător să privești înăuntru, dar sper să fie bine. Cuvintele dezvoltatorului sunt încurajatoare: „a durat mult pentru că BeOS nu era compatibil cu POSIX”, dar Haiku „în cea mai mare parte” este deja așa.
Portarea unei aplicații CLI simplă
Primul gând a fost să port aplicația , dar, după cum sa dovedit, asta este deja acum mult timp.
Prima încercare: nimic de urmărit
Ceea ce nu pot înțelege este că deja - în ciuda faptului că sistemul de operare în sine nu este încă versiunea 1.0.
A doua încercare: trebuie să rescrieți
Deci voi folosi , CLI pentru controlul imprimantei Brother P-Touch 770 pe care o folosesc pentru a imprima etichete.
Tipăresc pe el diverse etichete și poate ați văzut-o deja în articolul precedent. Puțin mai devreme, am scris un mic program Wrapper GUI în Python (din moment ce este în Gtk+, va trebui rescris, iar acesta este un motiv bun pentru a învăța).
Imprimanta de etichete Brother P-Touch 770. Va funcționa cu Haiku?
Managerul de pachete Haiku știe despre biblioteci și comenzi, așa că dacă primesc un mesaj „nu pot găsi libintl” când rulez configure - Tocmai am lansat pkgman install devel:libintl iar pachetul necesar va fi găsit. De asemenea pkgman install cmd:rsync. Ei bine, etc.
Cu excepția cazului în care acest lucru nu funcționează:
/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 foundPoate că udev este prea bazat pe Linux și, prin urmare, nu există pentru Haiku. Ceea ce înseamnă că trebuie să editez codul sursă pe care încerc să îl compilez.
Eh, nu poți sări peste cap și nici nu știu de unde să încep.
A treia încercare
Ar fi frumos să ai tmate pentru Haiku, atunci le-aș permite dezvoltatorilor Haiku să se conecteze la sesiunea mea de terminal - în cazul în care ceva nu merge bine. Instrucțiunile sunt destul de simple:
./autogen.sh
./configure
make
make installArată bine, așa că de ce să nu încerci pe 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 acest pas deschid HaikuDepot și caut curses.
S-a găsit ceva, care mi-a dat un indiciu pentru o interogare mai competentă:
/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 foundDin nou am fost la HaikuDepot și, bineînțeles, am găsit devel:msgpack_c_cpp_devel. Care sunt aceste nume ciudate?
/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 1La acest pas, mi-am dat seama că portarea unui program pe Haiku necesită mult mai multe cunoștințe decât este nevoie pentru o reconstrucție simplă.
Am vorbit cu dezvoltatorii prietenoși Haiku, s-a dovedit că există o eroare în msgpack și după câteva minute văd un patch în HaikuPorts. Văd cu ochii mei cum s-a corectat pachetul (buildslave - mașini virtuale).
Construirea mesajului msgpack corectat pe buildmaster
Între momente, trimit un patch în amonte .
Cinci minute mai târziu, pachetul de mesaje actualizat este deja disponibil î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.Neașteptat de bine. Am spus asta?!
Revin la problema initiala:
/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 1Acum se pare că msgpack nu este de vină. Comentez IMAXLABEL в tty.c după cum urmează:
tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|/*IMAXBEL|*/ISTRIP);Rezultat:
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.Ei bine, iată-ne din nou... Apropo:
/Haiku/home/tmate> ./configure | grep -i OPENAT
checking for openat... novă spune unde să sapi:
/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.Aici am postat .
Mi-au explicat că mai există ceva în libnetwork pe lângă libresolv pe Haiku. Se pare că codul trebuie editat în continuare. Trebuie sa te gandesti...
find . -type f -exec sed -i -e 's|lresolv|lnetwork|g' {} ;Eterna întrebare: ce se întâmplă?
/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 foundAcelași lucru, doar la profil. Googled și . Daca adaugati -lssp „uneori” ajută, încerc:
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp"
(...)/Haiku/home/tmate> make
(...)/Haiku/home/tmate> ./tmateWow! Începe! Dar…
[tmate] ssh.tmate.io lookup failure. Retrying in 2 seconds (non-recoverable failure in name resolution)Voi încerca să depanez :
/Haiku/home/tmate> strace -f ./tmate >log 2>&1„Identificarea portului greșit” este deja ca o carte de vizită . Poate cineva are idee ce este în neregulă și cum se poate remedia? Dacă da, voi actualiza articolul. Link către .
Portarea aplicației GUI la Qt.
Aleg o aplicație QML simplă.
/> 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!Chiar simplu. Mai putin de un minut!
Aplicații de ambalare în hpkg folosind haikuporter și haikuports.
Cu ce ar trebui să încep? Nu există o documentare simplă, merg pe canalul #haiku de pe irc.freenode.net și aud:
- Echipă
package- o modalitate de nivel scăzut de a crea pachete. În cea mai mare parte, PackageInfo este suficient pentru ea, așa cum este descris în secțiunea „Transformarea într-un pachet .hpkg adecvat” - trebuie sa fac ceva
- Pot folosi (se prăbușește pentru mine, )
Nu este clar ce să faci. Cred că am nevoie de un ghid pentru începători în stilul Hello World, în mod ideal, un videoclip. Ar fi bine să aveți și o introducere convenabilă în HaikuPorter, așa cum se face în GNU hello.
Am citit urmatoarele:
haikuportereste un instrument pentru crearea de proiecte comune de pachete pentru Haiku. Folosește depozitul HaikuPorts ca bază pentru toate pachetele. Rețetele Haikuporter sunt folosite pentru a crea pachete.
În plus, aflu că:
Nu este nevoie să stocați rețete în stocarea HaikuPorts. Puteți face un alt depozit, puteți pune rețetele în el și apoi indicați haikuporter către el.
Exact ceea ce am nevoie - dacă nu caut o modalitate de a elibera public pachetul. Dar acesta este un subiect pentru o altă postare.
Instalarea haikuporter și 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.confScrierea unei rețete
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
}Asamblarea rețetei
Salvez fișierul sub numele QtQuickApp-1.0.recipe, dupa care ma lansez aikuporter -S ./QuickApp-1.0.recipe. Dependențele sunt verificate pentru toate pachetele din depozit , care durează ceva timp. Mă duc să iau o cafea.
De ce naiba ar trebui să se facă această verificare pe mașina mea locală și nu central pe server o dată pentru toată lumea?
Potrivit dl. waddlesplash:
Cu astfel încât să poți rescrie orice fișier din depozit 😉 Puteți să optimizați puțin acest lucru, calculând informațiile necesare atunci când este necesar, deoarece ultimele modificări efectuate sunt destul de rare.
~/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 repositorySe pare că nu există un fișier de rețetă obișnuit care să conțină codul sursă al aplicației tale. Trebuie să-l păstrați într-un depozit în format HaikuPorts.
~/QtQuickApp> mv QtQuickApp-1.0.recipe ../haikuports/app-misc/QtQuickApp/
~/QtQuickApp> ../haikuport
~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipeAcest fapt face ca asamblarea să fie mai greoaie. Nu-mi place în mod deosebit, dar cred că este necesar pentru ca în cele din urmă să apară tot software-ul open source în HaikuPorts.
Primesc următoarele:
~/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.Ce s-a întâmplat? După ce citesc irc, fac:
~/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!A apărut o întrebare interesantă. Dacă adaug o sumă de verificare la rețetă - se va potrivi cu cel mai recent git commit pentru integrare continuă? (Dezvoltatorul confirmă: „Nu va funcționa. Rețetele sunt concepute pentru a fi relativ stabile.”)
Pentru distracție, adăugați la rețetă:
CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"Încă nu sunt mulțumit:
~/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.gitCe face? La urma urmei, acesta este un depozit git, codul este deja acolo direct, nu este nimic de despachetat. Din punctul meu de vedere, instrumentul ar trebui să fie suficient de inteligent pentru a nu căuta un dispozitiv de despachetare dacă este deasupra url-ului GitHub.
Poate că uri git:// va funcționa
SOURCE_URI="git://github.com/probonopd/QtQuickApp.git"Acum se plânge așa:
Downloading: git://github.com/probonopd/QtQuickApp.git ...
Error: Downloading from unsafe sources is disabled in haikuports.conf!Hmm, de ce este totul atât de complicat, de ce nu poți „doar să lucrezi”? La urma urmei, nu este atât de neobișnuit să construiești ceva din GitHub. Fie că este vorba de instrumente care funcționează imediat, fără a fi nevoie de configurare, sau așa cum le numesc eu „furioasă”.
Poate va funcționa așa:
SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"Nu. Încă primesc această eroare ciudată și fac,
sed -i -e 's|#ALLOW_UNSAFE_SOURCES|ALLOW_UNSAFE_SOURCES|g' /boot/home/config/settings/haikuports.confMă îndrept puțin mai departe, dar de ce țipă la mine (GitHub nu este securizat!) și încă încearcă să despacheteze ceva.
În conformitate cu :
Ei bine, da, motivul a fost dorința de a verifica integritatea datelor primite pentru asamblare. Una dintre opțiuni este să verificați suma de verificare a arhivei, dar puteți, desigur, să hașați fișiere individuale, care nu vor fi implementate, deoarece durează mult mai mult. Consecința acestui lucru este „nesiguranța” git și a altor VCS. Cel mai probabil, acesta va fi întotdeauna cazul, deoarece crearea unei arhive pe GitHub este destul de ușoară și adesea mai rapidă. Ei bine, pe viitor, poate că mesajul de eroare nu va mai fi atât de strălucitor... (nu mai îmbinăm astfel de rețete î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 2Din vechiul obicei, mă duc să întreb oameni buni pe canalul #haiku de pe rețeaua irc.freenode.net. Și unde aș fi fără ei? După indicație, mi-am dat seama că ar trebui să folosesc:
srcGitRev="d0769f53639eaffdcd070bddfb7113c04f2a0de8"
SOURCE_URI="https://github.com/probonopd/QtQuickApp/archive/$srcGitRev.tar.gz"
SOURCE_DIR="QtQuickApp-$srcGitRev"
CHECKSUM_SHA256="db8ab861cfec0ca201e9c7b6c0c9e5e828cb4e9e69d98e3714ce0369ba9d9522"Bine, a devenit clar ce face - descarcă o arhivă cu codul sursă al unei anumite versiuni. Este o prostie, din punctul meu de vedere, și nu tocmai ceea ce mi-am dorit, și anume, să descarc cea mai recentă revizuire din ramura master.
Unul dintre dezvoltatori a explicat astfel:
Avem propriul nostru CI, așa că tot ceea ce este plasat în depozitul de haikuports va fi împachetat pentru toți utilizatorii și nu vrem să riscăm să colectăm și să livrăm „totul în cea mai recentă versiune în amonte”.
Înțeles! În orice caz, așa s-a întâmplat:
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
(...)Repetă acest lucru la infinit. Se pare că aceasta este o eroare (există o aplicație? Nu am putut să o găsesc).
С haikuporter și depozit Nu are o senzație „doar funcționează”, dar, în calitate de dezvoltator, sunt câteva lucruri care îmi plac la lucrul cu Haiku. În cea mai mare parte, este similar cu Serviciul Open Build, un set de instrumente pentru construirea de versiuni Linux: extrem de puternic, cu o abordare sistematică, dar exagerat pentru mica mea aplicație „hello world”.
Din nou, potrivit dl. waddlesplash:
Într-adevăr, HaikuPorter este destul de strict în mod implicit (în plus, există un mod lint, precum și un mod strict pentru a-l face și mai strict!), dar numai pentru că creează pachete care vor funcționa, mai degrabă decât să creeze pachete. De aceea se plânge de dependențe nedeclarate, biblioteci neimportate corect, versiuni incorecte etc. Scopul este de a surprinde toate problemele, inclusiv cele viitoare, înainte ca utilizatorul să știe despre asta (de aceea nu a fost posibil să se instaleze avrdude, deoarece dependența a fost de fapt specificată în rețetă). Bibliotecile nu sunt doar pachete individuale sau chiar versiuni SO specifice. HaikuPorter se asigură că toate acestea sunt respectate în rețetele în sine pentru a evita erorile în timpul execuției.
În principiu, acest nivel de rigoare este justificat la crearea unui sistem de operare, dar mi se pare inutil pentru o aplicație „hello world”. Am decis să încerc altceva.
Crearea de aplicații în format hpkg utilizând comanda „creare pachet”.
Poate, Instrucțiunile simple vor funcționa mai bine pentru mine?
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 menuNeașteptat de rapid, neașteptat de simplu, neașteptat de eficient. Exact cum imi place mie, minunat!
Instalare - ce și unde?
S-a mutat fișierul QtQuickApp.hpkg în ~/config/packagesfolosind un manager de fișiere, după care a apărut în mod magic QtQuickApp ~/config/apps.
Din nou, neașteptat de rapid, simplu și eficient. Uimitor, incredibil!
Dar... (unde am fi noi fără ei!)
Aplicația încă lipsește din lista de meniuri de aplicații și din QuickLaunch. Cred că știu deja cum să o repar. În managerul de fișiere mut QtQuickApp.hpkg de la ~/config/packages în /system/packages.
Nu, încă lipsește. Aparent, eu (ei bine, și instrucțiunile) am omis ceva.
După ce m-am uitat la fila „Conținut” din HaikuDepot pentru alte aplicații, am văzut că există fișiere precum /data/mimedb/application/x-vnd... ceea ce este și mai remarcabil este /data/deskbar/menu/Applications/….
Ei bine, ce ar trebui să pun acolo? Haide...
mkdir -p data/deskbar/menu/Applications/
( cd data/deskbar/menu/Applications ; ln -s ../../../../apps/QtQuickApp . )
package add QtQuickApp.hpkg apps dataSunt destul de sigur că acest truc va funcționa, dar întrebările rămân: de ce este necesar, pentru ce este? Cred că acest lucru distruge impresia generală că sistemul este atât de sofisticat.
După cum a explicat dl. waddlesplash:
Uneori există aplicații de care alte aplicații au nevoie, dar nu sunt în meniu. De exemplu, LegacyPackageInstaller în captura de ecran, procesând arhive .pkg în format BeOS. Aș dori ca utilizatorii să le instaleze, dar prezența lor în meniu va duce la confuzie.
Din anumite motive, mi se pare că există o soluție mai simplă, de exemplu Hidden=true în dosare .desktop pe Linux. De ce să nu faceți din informațiile „ascunse” o resursă și un atribut al sistemului de fișiere?
Ceea ce nu este deosebit de subtil este numele (unei) aplicații care arată meniul, deskbar, legat rigid pe parcurs.
Domnul. waddlesplash explică acest lucru:
„Bara de birou” în acest caz ar trebui înțeleasă ca un fel de termen general (în același mod cu „bara de activități”, care se referă atât la aplicația Windows, cât și la conceptul general). Ei bine, de când asta
deskbar, nu „Deskbar”, acest lucru poate fi, de asemenea, înțeles într-un mod similar.
2 directoare „aproape identice” cu aplicații în ele
De ce există 2 directoare cu aplicații și, de asemenea, de ce este QtQuickApplication-ul meu într-unul, dar nu în celălalt? (La urma urmei, acesta nu este unul de sistem, ci unul de al doilea utilizator, ceea ce mi-ar fi de înțeles personal).
Sunt foarte confuz și cred că acest lucru ar trebui unificat.
comentariu de dl. waddlesplash
Catalogul de aplicații conține aplicații care nu sunt necesare în meniu. Dar situația cu meniul chiar trebuie îmbunătățită, pentru a-l face mai personalizabil.
Aplicație, sau nu se va întâmpla 😉
M-am întrebat: este cu adevărat necesar să găzduiești aplicații în /system/apps, dacă utilizatorii le văd acolo, nu este de dorit. Poate ar fi mai bine să le plasați într-un alt loc unde utilizatorul să nu le întâlnească? La fel cum se face în Mac OS X, unde conținutul pachetelor .app, care nu ar trebui să fie vizibil pentru utilizator în /Applications, ascunzându-se în adâncurile /System/Library/…“`.
Dar dependențe?
Cred că merită să specifici cumva dependențele, nu? Qt poate fi considerat implicit o parte obligatorie a instalării Haiku? Nu! Qt nu este instalat implicit. Poate un generator de pachete să detecteze automat dependențele verificând fișierele ELF? Mi s-a spus că HaikuPorter chiar face asta, dar package Nu. Asta pentru că este doar un „constructor de pachete” care doar creează fișiere pe cont propriu hpkg.
Ar trebui să devină Haiku mai sofisticat prin adăugarea unei politici conform căreia un pachet nu ar trebui să aibă dependențe de pachetele din afara Haiku? haikuports? (Mi-aș dori, deoarece o astfel de politică ar face lucrurile mult mai ușoare - sistemul ar putea rezolva automat dependențele fiecărui pachet descărcat de oriunde, fără să se încurce cu surse suplimentare de pachete.)
Domnul. waddlesplash explică:
Nu ne-am dori să limităm atât de mult libertatea dezvoltatorilor, pentru că este evident că dacă CompanyX dorește să susțină propriul set de software cu dependențe (și, prin urmare, un depozit), o va face complet liber.
În acest caz, ar putea merita să recomandați ca pachetele terțe să evite dependențele de orice nu este inclus în haikuports, împachetând complet tot ce este necesar cu aplicația. Dar cred că acesta este un subiect pentru un articol viitor din această serie. [Se îndreaptă autorul către AppImage? — aprox. traducător]
Adăugarea unei pictograme de aplicație
Ce se întâmplă dacă vreau să adaug una dintre pictogramele încorporate îngrijite la resursele aplicației mele nou create? Se pare că acesta este un subiect uimitor, așa că va fi baza pentru următorul articol.
Cum se organizează construirea continuă a aplicațiilor?
Imaginați-vă un proiect precum Inkscape (da, sunt conștient că nu este încă disponibil în Haiku, dar este convenabil să fie afișat pe el). Au un depozit de cod sursă https://gitlab.com/inkscape/inkscape.
De fiecare dată când cineva își comite modificările în depozit, se lansează conductele de construcție, după care modificările sunt testate, construite automat și aplicația împachetată în diverse pachete, inclusiv AppImage pentru Linux (un pachet de aplicații autonom care poate fi descărcat pentru testare locală indiferent de ce poate fi sau nu instalat pe sistem [Ştiam eu! — aprox. traducător]). Același lucru se întâmplă cu fiecare cerere de îmbinare a ramurilor, astfel încât să puteți descărca aplicația construită din codul propus în cererea de îmbinare înainte de fuzionare.
Solicitările de îmbinare cu stările de compilare și capacitatea de a descărca binarele compilate dacă construirea are succes (marcate cu verde)
Compilarea rulează în containere Docker. GitLab oferă runneri gratuiti pe Linux și cred că ar putea fi posibil să vă includeți propriile runners (apropo, nu văd cum ar funcționa asta pentru sisteme precum Haiku, despre care știu că nu au Docker sau echivalent, dar de asemenea, pentru FreeBSD nu există Docker, deci această problemă nu este exclusivă pentru Haiku).
În mod ideal, aplicațiile Haiku pot fi construite într-un container Docker pentru Linux. În această situație, ansamblul pentru Haiku poate fi introdus în conductele existente. Există compilatoare încrucișate? Sau ar trebui să emulez toate Haiku-urile dintr-un container Docker folosind ceva de genul QEMU/KVM (presupunând că va funcționa așa în Docker)? Apropo, multe proiecte folosesc principii similare. De exemplu, Scribus face acest lucru - este deja disponibil pentru Haiku. Într-o zi va veni ziua când voi putea trimite Atrageți solicitări către alte proiecte pentru a adăuga suport Haiku.
Unul dintre dezvoltatori explică:
Pentru alte proiecte care doresc să creeze singuri pachete, este acceptată metoda obișnuită CMake/CPack. Alte sisteme de compilare pot fi suportate apelând direct programul de compilare al pachetului, ceea ce este bine dacă oamenii sunt interesați de el. Experiența arată: până acum nu a existat prea mult interes, așa că haikuporter a funcționat la fel de convenabil pentru noi, dar, în cele din urmă, ambele metode ar trebui să funcționeze împreună. Ar trebui să introducem un set de instrumente pentru crearea încrucișată a software-ului din Linux sau orice alt sistem de operare pentru server (Haiku nu este proiectat să ruleze pe servere).
Fac ovație în picioare. Utilizatorii obișnuiți de Linux poartă toată această încărcătură suplimentară și bagaj suplimentar (securitate, control strict etc.) care este necesar pentru un sistem de operare pe server, dar nu și pentru unul personal. Așa că sunt complet de acord că posibilitatea de a construi aplicații Haiku pe Linux este calea de urmat.
Concluzie
Portarea aplicațiilor POSIX pe Haiku este posibilă, dar poate fi mai costisitoare decât o reconstrucție tipică. Cu siguranță aș fi blocat cu asta pentru o lungă perioadă de timp dacă nu ar fi ajutorul oamenilor de pe canalul #haiku de pe rețeaua irc.freenode.net. Dar nici măcar ei nu au văzut întotdeauna imediat ce era în neregulă.
Aplicațiile scrise în Qt sunt o excepție ușoară. Am creat o aplicație demo simplă fără probleme.
Construirea unui pachet pentru aplicații simple este, de asemenea, destul de ușoară, dar numai pentru cele „eliberate în mod tradițional”, adică. având arhive de cod sursă versionate destinate suportului în haikuports. Pentru o construcție continuă (build pentru fiecare comitere de modificări) cu GitHub, totul pare să nu fie atât de simplu. Aici Haiku se simte mai mult ca o distribuție Linux decât rezultatul pe un Mac, unde atunci când faceți clic pe butonul „Build” din XCode, obțineți un pachet .app, gata pentru a fi introdus într-o imagine de disc .dmg, pregătit pentru descărcare pe site-ul meu.
Construirea continuă a aplicațiilor bazate pe un sistem de operare „server”, de exemplu, Linux, va deveni cel mai probabil posibilă dacă există cerere din partea dezvoltatorilor, dar în acest moment proiectul Haiku are alte sarcini, mai presante.
Incearca-l tu insuti! La urma urmei, proiectul Haiku oferă imagini pentru pornire de pe DVD sau USB, generate . Pentru a instala, trebuie doar să descărcați imaginea și să o scrieți pe o unitate flash folosind
Aveti vreo intrebare? Vă invităm la limba rusă .
Prezentare generală a erorilor:
De la traducere: acesta este al cincilea articol din seria despre Haiku.
Lista articolelor:
Sursa: www.habr.com