🥇Ziua mea a cincea cu Haiku: să portăm puțin din program

TL;DR: Un novice a văzut Haiku pentru prima dată, încercând să porteze unele aplicații din lumea Linux.

Prima mea aplicație portată pentru Haiku, împachetată în formatul său hpkg

Recent Am descoperit Haiku, un sistem de operare pentru PC-uri neașteptat de bun.
Astăzi voi învăța să port noi aplicații pe acest sistem de operare. Principalul accent este descrierea primei experiențe de trecere la Haiku din perspectiva unui dezvoltator pentru Linux. Îmi cer scuze pentru greșelile stupide făcute în proces, deoarece nu a trecut o săptămână de când am încărcat Haiku pentru prima dată.

Vreau să ating trei obiective:

Portarea unei aplicații CLI simple
Portarea unei aplicații cu GUI pe Qt
Împachetarea lor apoi în format hpkg (deoarece încă mă gândesc la adaptarea AppDir și AppImage pentru Haiku…)

Să începem. În secțiunile documentația și instrumentelor pentru asigurarea securității,, precum și în wiki de la HaikuPorts am găsit direcția potrivită. Există chiar o carte online PDF BeOS: Portarea unei aplicații Unix.
467 de pagini - și asta încă din 1997! Să arunc o privire înăuntru este înfricoșător, dar sper la ce e mai bun. Cuvintele dezvoltatorului sunt încurajatoare: „a durat mult, deoarece BeOS nu a fost compatibil cu POSIX”, dar Haiku „în mare parte” este deja așa.

Portarea unei aplicații simple CLI

Prima mea gândire a fost să port o aplicație avrdude, dar, după cum s-a dovedit, aceasta a fost deja au realizat de mult timp.

Prima încercare: nimic de văzut

Ceea ce nu pot înțelege deloc este că deja de peste 10 ani aplicațiile sunt portate pentru Haiku — având în vedere că sistemul de operare nu are nici măcar versiunea 1.0.

A doua încercare: trebuie rescrisă

Așadar, voi folosi ptouch-770, CLI pentru gestionarea imprimantei Brother P-Touch 770, pe care o folosesc pentru a imprima etichete.
Imprim etichete diverse pe ea și, poate, ați văzut-o deja în articolul trecut. Cu puțin timp în urmă, am scris un mic program de interfață cu GUI pe Python (deoarece este pe Gtk+ — va trebui să rescriu, ceea ce reprezintă o bună ocazie de a învăța).

Imprimanta de etichete Brother P-Touch 770. Va funcționa sub Haiku?

Managerul de pachete Haiku cunoaște bibliotecile și comenzile, așa că dacă primesc mesajul „can’t find libintl” la pornire configure — pur și simplu rulez pkgman install devel:libintl și pachetul necesar va fi găsit. La fel pkgman install cmd:rsync. Și așa mai departe.

Cu excepția cazurilor când 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 found

Poate că udev este prea linux-ish, de aceea nu există pentru Haiku. Ce înseamnă necesitatea de a modifica codul sursă pe care încerc să-l compilesc.
Of, nu pot să sar peste cap, și nici măcar nu știu de unde să încep.

A treia încercare

Ar fi bine să am tmate pentru Haiku, atunci aș permite dezvoltatorilor Haiku să se conecteze la sesiunea mea terminal — în caz că ceva nu merge bine. Instrucțiunile sunt destul de simple:

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

Arată bine, așa că de ce să nu încerc asta 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 cerere mai corectă:

/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

M-am dus din nou la HaikuDepot și, desigur, am găsit devel:msgpack_c_cpp_devel. Ce 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 1

În acest pas, mi-am dat seama că portarea programului pe Haiku necesită mult mai multe cunoștințe decât este nevoie pentru o simplă recompilare.
Am vorbit cu dezvoltatorii prietenoși ai Haiku, s-a dovedit că există o eroare în msgpack, iar după câteva minute văd un patch în HaikuPorts. Observ cu ochii mei cum pachetul corectat se compilează aici (buildslave — mașini virtuale).

Compilarea msgpack corectat pe buildmaster

Între timp, trimit patch-ul în upstream pentru adăugarea suportului Haiku în msgpack.

Cinci minute mai târziu, msgpack 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.

Surprinzător de bine. Asta am spus?!

Revin la sarcina inițială:

/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

Acum pare că msgpack nu este vinovat. Comentez IMAXLABEL în tty.c așa:

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

Rezultatul:

osdep-unknown.c: În funcția 'osdep_get_cwd':
osdep-unknown.c:32:19: avertizare: parametru nefolosit 'fd' [-Wunused-parameter]
osdep_get_cwd(int fd)
               ~~~~^~
make: *** Nu există regulă pentru a face ținta 'compat/forkpty-unknown.c', necesară pentru 'compat/forkpty-unknown.o'.  Opriți.

Ei bine, din nou... Apropo:

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

mr. waddlesplash indică unde să caut:

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

Mi s-a explicat că la libresolv pe Haiku există ceva în plus în libnetwork. Se pare că trebuie să corectez mai departe codul. Trebuie să mă gândesc...

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

Întrebarea veșnică: 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 found

Același lucru, doar că mai profund. Am căutat pe Google și am găsit asta. Dacă adaug -lssp «uneori» ajută, încerc:

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

Wow! Pornește! Dar...

[tmate] ssh.tmate.io lookup failure. Reîncerc în 2 secunde (eroare irreparabilă în rezolvarea numelui)

Voi încerca să debugghez, fișierul aici:

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

«ID de port greșit» - asta deja sună ca o vizită de card haiku.Poate cineva știe ce nu este în regulă și cum să remedieze? Dacă este cazul, voi actualiza articolul. Linkul pentru GitHub.

Portarea unei aplicații GUI pe Qt.

Aleg o aplicație simplă 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!

Chiar foarte simplu. Sub un minut!

Ambalarea aplicațiilor în hpkg folosind haikuporter și haikuports.

De unde să încep? Nu există documentație simplă, merg pe canalul #haiku în irc.freenode.net și aud:

Comanda pachet — o metodă de bază pentru a crea pachete. În cea mai mare parte, este suficient să folosești PackageInfo, așa cum este descris în secțiunea „Transformarea într-un pachet .hpkg corespunzător”
Trebuie să fac ceva atâtea
Se poate utiliza hpkg-creator (îmi dă crash, raport de erori)

Nu știu ce să fac. Cred că am nevoie de un ghid pentru începători în stilul „Salut, Lume!”, ideal ar fi un videoclip. Ar fi bine să am și o introducere prietenoasă în HaikuPorter, așa cum este în GNU hello.

Citesc următoarele:

haikuporter este un instrument pentru a crea proiecte comune de pachete pentru Haiku. Folosește repository-ul HaikuPorts ca bază pentru toate pachetele. Pentru a crea pachete, se folosesc rețete haikuporter.

De asemenea, aflu că:

Nu este necesar să păstrezi rețetele în repository-ul HaikuPorts. Poți crea un alt repository, să pui acolo rețetele, după care să specifici haikuporter pe el.

Exact ce îmi trebuie — dacă nu caut o modalitate de a publica pachetul. Dar asta este o temă 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/ # face-l executabil din orice locație
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

Scrierea rețetei

SUMMARY="Aplicație demo QtQuick"
DESCRIPTION="QtQuickApp este o aplicație demo QtQuick pentru testarea portării și ambalării pentru Haiku"
HOMEPAGE="https://github.com/probonopd/QtQuickApp"
COPYRIGHT="Niciunul"
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
}

Construirea rețetei

Salvez fișierul sub numele QtQuickApp-1.0.recipe, după care lansez haikuporter -S ./QuickApp-1.0.recipe. Verificările dependențelor pentru toate pachetele din repository haikuports, ceea ce durează ceva timp. O să mă duc să-mi beau o cafea.

Dar de ce ar trebui să fac această verificare pe mașina mea locală, și nu centralizat pe server o dată pentru toți?

Conform lui mr. waddlesplash:

Pentru că oricine poate modifica orice fișier în repository 😉 Se poate optimiza puțin, calculând informațiile necesare doar atunci când este nevoie, pentru că ultimele modificări sunt destul de rare.

~/QtQuickApp> haikuporter QtQuickApp-1.0.recipe
Verific dacă trebuie actualizate informațiile de dependență ...
Caut informații de dependență învechite ...
Eroare: QtQuickApp nu a fost găsit în repository

Se 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ăstrezi în depozit în format HaikuPorts.

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

Acest fapt face ca compilarea să fie mai complicată. Nu-mi place foarte mult, dar cred că este necesar pentru ca, în cele din urmă, toate software-urile cu sursă deschisă să apară în HaikuPorts.

Obțin următorul rezultat:

~\/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe\nChecking if any dependency-infos need to be updated ...\n        updating dependency infos of QtQuickApp-1.0\nLooking for stale dependency-infos ...\nError: QtQuickApp-1.0.recipe not found in tree.

Ceva nu este în regulă? După ce am citit pe irc, fac următoarele:

~\/QtQuickApp> haikuporter -S QtQuickApp\nChecking if any dependency-infos need to be updated ...\n        updating dependency infos of QtQuickApp-1.0\nLooking for stale dependency-infos ...\n----------------------------------------------------------------------\napp-misc::QtQuickApp-1.0\n        \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe\n----------------------------------------------------------------------Downloading: https:\/\/github.com\/probonopd\/QtQuickApp.git ...\n--2019-07-14 16:12:44--  https:\/\/github.com\/probonopd\/QtQuickApp.git\nResolving github.com... 140.82.118.3\nConnecting to github.com|140.82.118.3|:443... connected.\nHTTP request sent, awaiting response... 301 Moved Permanently\nLocation: https:\/\/github.com\/probonopd\/QtQuickApp [following]\n--2019-07-14 16:12:45--  https:\/\/github.com\/probonopd\/QtQuickApp\nReusing existing connection to github.com:443.\nHTTP request sent, awaiting response... 200 OK\nLength: unspecified [text\/html]\nSaving to: ‘\/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git’\n     0K .                                                     1.34M=0.06s\n2019-07-14 16:12:45 (1.34 MB\/s) - ‘\/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git’ saved [90094]\nValidating checksum of QtQuickApp.git\nWarning: ----- CHECKSUM TEMPLATE -----\nWarning: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"\nWarning: -----------------------------\nError: No checksum found in recipe!

A apărut o întrebare interesantă. Dacă adaug o sumă de control în rețetă — va corespunde aceasta ultimei comenzi git pentru integrarea continuă? (Dezvoltatorul confirmă: „Nu va funcționa nimic. Rețetele sunt concepute să fie relativ stabile”).

Pentru glumă, adaugă în rețetă:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Încă nu mă mulțumește:

~\/QtQuickApp> haikuporter -S QtQuickApp\nChecking if any dependency-infos need to be updated ...\n        updating dependency infos of QtQuickApp-1.0\nLooking for stale dependency-infos ...\n----------------------------------------------------------------------\napp-misc::QtQuickApp-1.0\n        \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe\n----------------------------------------------------------------------\nSkipping download of source for QtQuickApp.git\nValidating checksum of QtQuickApp.git\nUnpacking source of QtQuickApp.git\nError: Unrecognized archive type in file \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git

Ce se întâmplă? Este un repository git, codul este deja acolo, nu este nevoie să fie dezarhivat. Din punctul meu de vedere, instrumentul ar trebui să fie suficient de inteligent pentru a nu căuta un dezarhivator dacă are un URL de la GitHub.

Poate va funcționa cu uri git://

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

Acum se plânge astfel:

Descărcare: git://github.com/probonopd/QtQuickApp.git ...
Eroare: Descărcarea din surse nesigure este dezactivată în haikuports.conf!

Hmm, de ce este totul atât de complicat, de ce nu poate „pur și simplu să fonctionneze”? Până la urmă, nu este atât de rar să poți compila ceva de pe GitHub. Instrumentele care funcționează direct, fără a necesita configurări, sau cum le numesc eu „bătăi de cap”, sunt mult mai bune.

Poate va merge așa:

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

Nu, încă primesc această eroare ciudată și fac așa cum este descris aici

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

Progresez un pic mai departe, dar de ce mă strigă (GitHub nu este sigur!) și tot încearcă să dezarhiveze ceva.

Conform mr. waddlesplash:

Ei bine, motivul a fost dorința de a verifica integritatea datelor primite pentru compilare. O opțiune este să compari suma de verificare a arhivei, dar, desigur, se pot face hash și fișierele individuale, ceea ce nu va fi implementat, deoarece durează mult mai mult timp. Aceasta este, de asemenea, cauza „nesiguranței” git și altor VCS. Cel mai probabil va fi întotdeauna așa, deoarece crearea unei arhive pe GitHub este destul de simplă și adesea mai rapidă. Poate că în viitor, mesajul de eroare nu va fi atât de strident… (nu mai comasăm astfel de rețete în HaikuPorts).

~/QtQuickApp> haikuporter -S QtQuickApp
Verific dacă trebuie actualizate informațiile despre dependență ...
Caut informații despre dependențe expirate ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Descărcare: git+https://github.com/probonopd/QtQuickApp.git ...
Atenție: SURSE NESIGURE SUNT RELE ȘI NU AR TREBUI SĂ FIE FOLOSITE ÎN PRODUCȚIE
Atenție: VĂ RUGĂM SĂ TRECEȚI LA O DESCĂRCARE STATICĂ A ARHIVEI CU SUMA DE VERIFICARE ÎN CEA MAI SCURTĂ TIMP!
Se clonează în repository-ul gol '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
Se dezarhivează sursa din QtQuickApp.git
tar: /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0: Nu se poate deschide: Nu există astfel de fișiere sau directoare
tar: Eroarea nu este recuperabilă: ieșire acum
Comanda 'git archive HEAD | tar -x -C "/boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0"' a returnat un statut de ieșire diferit de zero 2

Din vechea obișnuință, mă duc să cer ajutorul oamenilor buni pe canalul #haiku din rețeaua irc.freenode.net. Și unde aș fi fără ei? După o sugestie, am înțeles că trebuie să folosesc:

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

Bine, este clar ce face — descarcă un arhivă cu sursele unei anumite revizii. Din punctul meu de vedere, este stupid și nu este tocmai ceea ce mi-aș fi dorit, adică — să descarc ultima revizie de pe ramura principală.

Unul dintre dezvoltatori a explicat astfel:

Avem propriul nostru CI, astfel că tot ce este plasat în repository-ul haikuports va fi ambalat pentru toți utilizatorii, iar noi nu vrem să ne asumăm riscuri compilând și livrând „tot ce este în ultima versiune în upstream”.

Am înțeles! Oricum, a ieșit ceva de genul:

așteptând activarea pachetului de construcție QtQuickApp-1.0-1
așteptând activarea pachetului de construcție QtQuickApp-1.0-1
așteptând activarea pachetului de construcție QtQuickApp-1.0-1
așteptând activarea pachetului de construcție QtQuickApp-1.0-1
așteptând activarea pachetului de construcție QtQuickApp-1.0-1
(...)

Repetă așa la nesfârșit. Se pare că este o eroare (există o cerere? eu nu am găsit).

Cu haikuporter și depozitul haikuports Nu se simte nivelul de „pur și simplu funcționează”, dar, ca dezvoltator, îmi plac unele aspecte ale lucrului cu Haiku. În mare parte este similar cu Open Build Service — un set de instrumente pentru construirea distribuțiilor Linux: extrem de puternic, cu o abordare sistemică, dar excesiv pentru aplicația mea mică de tip „hello world”.

Din nou, conform lui mr. waddlesplash:

Într-adevăr, HaikuPorter este destul de strict în mod implicit (plus există modul lint, precum și modul strict, care îl fac și mai strict!), dar doar pentru că creează pachete care vor funcționa, nu doar creează pachete. De aceea se plânge de dependențele neanunțate, bibliotecile importate incorect, versiunile greșite etc. Scopul este de a prinde toate problemele fără excepție, inclusiv pe cele viitoare, înainte ca utilizatorul să afle despre ele (de aceea nu a fost posibil să instalez avrdude, deoarece rețeta a indicat de fapt o dependență). Bibliotecile nu sunt doar pachete separate și nici măcar versiuni SO definite. HaikuPorter se asigură că respectă totul în rețete, pentru a evita erorile în timpul execuției.

În principiu, un astfel de nivel de strictețe este justificat în crearea unui sistem de operare, dar mi se pare excesiv pentru o aplicație „hello world”. Am decis să încerc ceva diferit.

Construirea aplicațiilor în format hpkg, folosind comanda „package create”

Poate că aceasta o instrucțiune simplă mi s-ar potrivi mai bine?

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

summary "Aplicație demo QtQuick"
description "QtQuickApp este o aplicație demo QtQuick pentru testarea portării și ambalării în Haiku"

packager "probono"
vendor "probono"

copyrights "probono"
licenses "MIT"

provides {
  QtQuickApp = 1.0-1
}requires {
  qt5
}
EOFpackage create -b QtQuickApp.hpkg
package add QtQuickApp.hpkg apps# Consultați mai jos dacă doriți ca aplicația
# să apară și în meniu

Incredibil de rapid, incredibil de simplu, incredibil de eficient. Exact așa cum îmi place, uimitor!

Instalare — ce și unde?

Am mutat fișierul QtQuickApp.hpkg în ~ /config/packages, folosind managerul de fișiere, după care QtQuickApp a apărut magic în ~ /config/apps.
Iarăși incredibil de rapid, simplu și eficient. Uimitor, incredibil!

Dar… (unde s-ar putea fără ele!)

Aplicația lipseste încă din lista aplicațiilor și din QuickLaunch. Cred că deja știu cum să repar asta. În managerul de fișiere, mut QtQuickApp.hpkg din ~ /config/packages în /system/packages.

Nu, încă lipseste. Se pare că eu (ei bine, și instrucțiunea) am omis ceva.

Verificând tab-ul „Contents” în HaikuDepot pentru alte aplicații, am observat că există fișiere de tipul /data/mimedb/application/x-vnd... ceea ce este și mai notabil, /data/deskbar/menu/Applications/….

Ei bine, ce să pun acolo? Hmm…

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

Sunt încrezător că acest truc va funcționa, dar mai am întrebări: de ce este necesar, pentru ce este necesar? Cred că strică impresia generală că sistemul este destul de rafinat.

A explicat mr. waddlesplash:

Uneori există aplicații de care au nevoie alte aplicații, dar nu în meniu. De exemplu, LegacyPackageInstaller din captura ta de ecran, care procesează arhive .pkg în format BeOS. Vrei ca utilizatorii să le instaleze, dar prezența lor în meniu va duce la confuzie.

Mi se pare că există o soluție mai simplă, de exemplu Hidden=true în fișierele .desktop pe Linux. De ce să nu faci informația „ascunsă” un resursă și un atribut al sistemului de fișiere?

Ceea ce nu este în mod special rafinat — numele (unei) aplicații care arată meniul, deskbar, este legat ferm în cale.

mr. waddlesplash explică despre aceasta:

„Deskbar” în acest caz ar trebui înțeles ca un termen general (aproape la fel ca „taskbar”, care se referă atât la aplicația Windows cât și la conceptul general). Dar având în vedere că aceasta deskbar, și nu „Deskbar”, se poate înțelege și într-un mod similar.

2 „cataloage aproape identice” de aplicații în ele

De ce există două cataloage cu aplicații și de ce în unul dintre ele aplicația mea QtQuickApplication este prezentă, iar în celălalt nu? (Pentru că acesta nu este un catalog sistemic, ci unul destinat utilizatorului, ceea ce ar fi clar pentru mine).
Chiar m-am amețit și cred că ar trebui să unificăm acest lucru.

comentariul lui mr. waddlesplash

În catalogul Apps există aplicații care nu sunt necesare în meniu. Totuși, situația din meniu trebuie cu adevărat îmbunătățită, pentru a-l face mai personalizabil.

Aplicare, sau acest lucru nu se va întâmpla 😉

M-am gândit: este cu adevărat necesar să plasăm aplicații în /system/apps, dacă utilizatorii nu doresc să le vadă acolo? Poate ar fi mai bine să le plasăm într-un alt loc, unde utilizatorul să nu se confrunte cu ele? La fel cum este făcut în Mac OS X, unde conținutul pachetelor .app, care nu ar trebui să fie vizibil utilizatorului în /Applications, este ascuns în adâncurile /System/Library/…«`.

Ce este cu dependențele?

Cred că ar trebui să specificăm cumva dependențele, nu-i așa? Poate fi considerat Qt o parte esențială a instalării implicite a Haiku? Nu! Qt nu este instalat implicit. Poate programul de construire a pachetului să identifice automat dependențele verificând fișierele ELF? Mi s-a spus că HaikuPorter face exact acest lucru, dar pachet nu. Totul se datorează faptului că este pur și simplu un „constructor de pachete”, care în sine creează doar fișiere. hpkg.

Ar trebui să facem Haiku mai sofisticat, adăugând o politică conform căreia un pachet să nu aibă dependențe de pachete care nu fac parte din haikuports? (Мне бы так хотелось, поскольку подобная политика значительно облегчает задачу — система смогла бы автоматически разрешить зависимости каждого пакета, загружаемого откуда угодно, без возни с дополнительными источниками пакетов).

mr. waddlesplash explică:

Nu ne-ar plăcea să restricționăm libertatea dezvoltatorilor atât de mult, deoarece este evident că, dacă CompaniaX dorește să sprijine propriul său set de software cu dependențe (și, prin urmare, un depozit) — sunt complet liberi să facă acest lucru.

În această situație, ar putea fi recomandat să evităm ca pachetele externe să aibă dependențe de ceva care nu face parte din haikuports, prin ambalarea completă a tot ceea ce este necesar cu aplicația. Dar, cred că aceasta este o temă pentru un articol viitor din această serie. [Autorul sugerează AppImage? — n. trad.]

Adăugarea unei icoane de aplicație

Dar ce fac dacă vreau să adaug în resursele aplicației mele nou-create una dintre icoanele elegante încorporate? Se pare că acesta este un subiect fascinant, așa că va deveni tema principală pentru următorul articol.

Cum să organizezi o construcție continuă a aplicațiilor?

Imaginați-vă un proiect similar cu Inkscape (da, știu că încă nu este disponibil în Haiku, dar este convenabil pentru ilustrare). Au un depozit de cod sursă. https://gitlab.com/inkscape/inkscape.
De fiecare dată când cineva își salvează modificările în depozit, se activează pipeline-urile de construcție, iar modificările sunt testate automat, compilate, aplicația este pachetată în diverse formate, inclusiv AppImage pentru Linux (un pachet autonom care poate fi descărcat pentru teste locale, indiferent de ce poate sau nu poate fi instalat pe sistem). [Știam eu! — nota traductorului]). La fel se întâmplă la fiecare cerere de fuziune a ramurilor, astfel încât poți descărca aplicația compilată din codul propus în cererea de fuziune, înainte de fuziune.

Cereri de fuziune cu statusuri ale construcției și posibilitatea de a descărca binarele compilate în cazul unei construcții de succes (marcate cu verde).

Construcția se desfășoară în containere Docker. GitLab oferă runners gratuiti pe Linux, și cred că este posibil să conectezi propriile runners (apropos, nu îmi pot imagina cum ar funcționa asta pentru sisteme precum Haiku, care, din câte știu, nu au Docker sau un echivalent, dar nici pentru FreeBSD nu există Docker, așa că această problemă nu este unică pentru Haiku).

Ideala ar fi ca construcția aplicațiilor pentru Haiku să se realizeze în interiorul unui container Docker pentru Linux. În acest caz, construcția pentru Haiku ar putea fi integrată în pipeline-urile existente. Există cross-compilatoare? Sau trebuie să emulăm întregul Haiku în interiorul containerului Docker, folosind ceva de genul QEMU/KVM (presupunând că va funcționa așa în interiorul Docker)? Apropo, multe proiecte utilizează principii similare. De exemplu, Scribus face asta — este deja disponibil pentru Haiku. Va veni ziua când voi putea trimite astfel de cereri de fuziune către alte proiecte pentru a adăuga suport pentru Haiku.

Unul dintre dezvoltatori explică:

Pentru alte proiecte care doresc să creeze pachete pe cont propriu, este suportată metoda standard CMake/CPack. Alte sisteme de construire pot fi sprijinite dacă se apelează direct programul de construire a pachetului, ceea ce este bine dacă oamenii sunt interesați de acest lucru. Experiența arată: până acum nu a existat un interes deosebit, așa că haikuporter a funcționat așa cum ne-a convenit, dar, în cele din urmă, ambele metode ar trebui să funcționeze împreună. Trebuie să prezentăm un set de instrumente pentru construirea încrucișată a software-ului din Linux sau orice alt sistem de operare server (Haiku nu este destinat funcționării pe servere).

Aplaud în picioare. Utilizatorii obișnuiți de Linux suportă toată această încărcătură suplimentară și bagajul adițional (securitate, control strict etc.), necesar unui sistem de operare server, dar nu unuia personal. Așadar, sunt complet de acord că posibilitatea de a construi aplicații pentru Haiku pe Linux este calea corectă.

Concluzie

Portarea aplicațiilor POSIX pe Haiku este posibilă, dar poate necesita mai multe resurse decât recompilarea obișnuită. Aș fi sigur că m-aș ocupa de aceasta pentru mult timp, dacă nu ar fi fost ajutorul oamenilor de pe canalul #haiku în rețeaua irc.freenode.net. Dar nici ei nu au văzut întotdeauna imediat ceea ce nu era în regulă.

Aplicațiile scrise pe Qt sunt o excepție ușoară. Am construit o aplicație demonstrativă simplă fără probleme majore.

Construirea pachetului pentru aplicații simple este, de asemenea, destul de ușoară, dar doar pentru cele „lansate în mod tradițional”, adică având arhive de cod sursă cu versiuni menite să fie suportate în haikuports. Pentru construcții continue (construirea la fiecare modificare) cu GitHub, totul pare să nu fie atât de simplu. Aici, Haiku se simte mai mult ca o distribuție Linux, decât ca un rezultat pe Mac, unde, prin apăsarea butonului „Construiește” în XCode, obțineți un pachet .app, gata de inserat în imaginea discului. .dmg, pregătit pentru a fi încărcat pe site-ul meu.
Construirea continuă a aplicațiilor pe baza unui sistem de operare „server”, cum ar fi Linux, va deveni probabil posibilă dacă va exista cerere din partea dezvoltatorilor, dar în prezent proiectul Haiku are alte sarcini mai urgente.

Încercați singuri! Proiectul Haiku oferă imagini pentru descărcare de pe DVD sau USB, care sunt generate zilnic. Pentru instalare, este suficient să descărcați imaginea și să o scrieți pe un stick USB folosind Etcher

Aveți întrebări? Vă invităm în canalul Telegram în limba rusă.

Revizuirea erorilor: Cum să te împuști în picior în C și C++. Colecția de rețete Haiku OS

De la autor traducere: acesta este al cincilea articol dintr-o serie despre Haiku.

Lista articolelor: Primul Al doilea Al treilea Al patrulea

Sursa: habr.com