🥇Il mio quinto giorno con Haiku: portiamo un po' di programmi

TL;DR: Un neofita ha visto Haiku per la prima volta, prova a portare alcuni programmi dal mondo Linux.

Il mio primo programma portato per Haiku, confezionato nel suo formato hpkg

Recentemente ho scoperto Haiku, un sistema operativo sorprendentemente buono per PC.
Oggi imparerò a trasferire nuovi programmi su questo sistema operativo. Il focus principale è descrivere la mia prima esperienza di transizione a Haiku dal punto di vista di uno sviluppatore Linux. Mi scuso per gli errori stupidi commessi durante il processo, visto che da quando ho caricato Haiku per la prima volta è passata meno di una settimana.

Voglio raggiungere tre obiettivi:

Portare un'applicazione CLI semplice
Portare un'applicazione GUI su Qt
Imballarli poi nel formato hpkg (poiché sto ancora pensando all'adattamento di AppDir e AppImage per Haiku…)

Cominciamo. Nelle sezioni documentazione e sviluppo, così come in wiki di HaikuPorts ho trovato la giusta direzione. C'è persino un libro PDF online BeOS: Porting Unix Applications.
467 pagine - e questo dal 1997! È spaventoso dare un'occhiata dentro, ma spero in bene. Le parole dello sviluppatore sono incoraggianti: “è difficile, perché BeOS non era compatibile con POSIX”, ma Haiku “per la maggior parte” lo è già.

Portare un'applicazione CLI semplice

La prima idea era di portare l'applicazione avrdude, ma, a quanto pare, è già stata ha smesso di molto tempo fa.

Primo tentativo: niente di cui preoccuparsi

Quello che non riesco a capire è che già da più di 10 anni le applicazioni vengono portate per Haiku — mentre il sistema operativo non ha nemmeno una versione 1.0.

Secondo tentativo: bisogna riscrivere

Quindi, userò ptouch-770, CLI per gestire la stampante Brother P-Touch 770, su cui stampo etichette.
Stampo diverse etichette con essa, e forse l'hai già vista nel mio articolo precedente. Poco prima ho scritto un piccolo programma wrapper con GUI in Python (dato che è su Gtk+ — dovrò riscriverlo, e questo è un buon motivo per imparare).

Stampante per etichette Brother P-Touch 770. Funzionerà su Haiku?

Il gestore pacchetti di Haiku è a conoscenza delle librerie e dei comandi, quindi se ricevo il messaggio «non riesco a trovare libintl» all'avvio configure — basta eseguire pkgman install devel:libintl e il pacchetto necessario sarà trovato. Allo stesso modo pkgman install cmd:rsync. Bene, e così via.

A meno che non funzioni:

/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

Potrebbe essere che udev sia troppo 'linuxoso', quindi non esiste per Haiku. Questo significa che è necessaria una modifica al codice sorgente che sto cercando di compilare.
Eh, non puoi saltare più in alto della testa, e non so nemmeno da dove cominciare.

Terzo tentativo

Sarebbe bello avere tmate per Haiku, allora permetterei agli sviluppatori di Haiku di connettersi alla mia sessione terminale, nel caso in cui qualcosa vada storto. Le istruzioni sono piuttosto semplici:

./autogen.sh
./configure
make
make install

Non sembra male, quindi perché non provare questo su 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

In questo passaggio apro HaikuDepot e cerco curses.
Qualcosa è stato trovato, che mi ha dato un suggerimento per una richiesta più accurata:

/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

Sono tornato in HaikuDepot e, ovviamente, ho trovato devel:msgpack_c_cpp_devel. Che nomi strani?

/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

In questo passaggio mi sono reso conto che portare il programma su Haiku richiede sicuramente più conoscenze di quelle necessarie per una semplice ricompilazione.
Ho parlato con gli sviluppatori amichevoli di Haiku, e ho scoperto che c'è un errore in msgpack, e dopo qualche minuto vedo un patch in HaikuPorts. Sto assistendo alla compilazione del pacchetto corretto qui (buildslave — macchine virtuali).

La compilazione di msgpack corretto su buildmaster

Nel frattempo, invio un patch a upstream per aggiungere supporto di Haiku in msgpack.

Cinque minuti dopo, msgpack aggiornato è già disponibile in 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.

Inaspettatamente buono. L'ho detto io?!

Torno al compito originale:

/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

Adesso sembra che msgpack non sia colpevole. Commento IMAXLABEL in tty.c in questo modo:

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

Risultato:

osdep-unknown.c: Nella funzione 'osdep_get_cwd':
osdep-unknown.c:32:19: avviso: parametro 'fd' non utilizzato [-Wunused-parameter]
osdep_get_cwd(int fd)
               ~~~~^~
make: *** Nessuna regola per fare l'obiettivo 'compat/forkpty-unknown.c', necessario per 'compat/forkpty-unknown.o'. Stop.

Ecco, di nuovo... A proposito:

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

mr. waddlesplash indica dove scavare:

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

Qui ho caricato config.log.

Mi è stato spiegato che a libresolv su Haiku c'è qualcos'altro in libnetwork. A quanto pare devo continuare a modificare il codice. Devo riflettere…

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

La classica domanda: cosa sta succedendo.

/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

Lo stesso, solo con un profilo. Ho cercato su Google e ho trovato questo. Se aggiungo -lssp a volte aiuta, provo:

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

Wow! Si avvia! Ma...

[tmate] ssh.tmate.io lookup failure. Riprovo tra 2 secondi (errore irrecuperabile nella risoluzione del nome)

Proverò a fare il debug, il file è qui:

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

«Bad port ID» — è già come un biglietto da visita haiku.Forse qualcuno ha idea di cosa non va e come sistemarlo? Se c'è bisogno, aggiornerò l'articolo. Link a GitHub.

Porting di un'applicazione GUI su Qt.

Scelgo una semplice applicazione 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!

Realmente semplice. Meno di un minuto!

Imballaggio di applicazioni in hpkg utilizzando haikuporter e haikuports.

Da dove cominciare? Non ci sono documentazioni più semplici, vado sul canale #haiku in irc.freenode.net e sento:

Team pacchetto — metodo a basso livello per la creazione di pacchetti. Per la maggior parte, basta PackageInfo, come descritto nella sezione «Fare di esso un vero pacchetto .hpkg»
Devo fare qualcosa di questo tipo
Può essere usato hpkg-creator (mi si blocca, rapporto di errore)

Non è chiaro cosa fare. Suppongo che mi serva un tutorial per principianti in stile «Ciao, Mondo!», idealmente un video. Sarebbe utile anche avere una comoda introduzione a HaikuPorter, come fatto in GNU hello.

Leggo quanto segue:

haikuporter è uno strumento per la creazione di progetti di pacchetti comuni per Haiku. Utilizza il repository HaikuPorts come base per tutti i pacchetti. I pacchetti vengono creati utilizzando le ricette di haikuporter.

Inoltre scopro che:

Non è necessario mantenere le ricette nel repository HaikuPorts. Può fare un altro repository, metterci le ricette e poi indicare haikuporter su di esso.

È proprio quello di cui ho bisogno — a meno che non si stia cercando un modo per pubblicare il pacchetto. Ma questo è un argomento per un altro post.

Installazione di haikuporter e 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/ # rendilo eseguibile da qualsiasi luogo
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

Scrittura della ricetta

SUMMARY="Demo dell'applicazione QtQuick"
DESCRIPTION="QtQuickApp è una demo dell'applicazione QtQuick per testare il porting e l'imballaggio di Haiku"
HOMEPAGE="https://github.com/probonopd/QtQuickApp"
COPYRIGHT="Nessuno"
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
}

Compilazione della ricetta

Salvo il file con il nome QtQuickApp-1.0.recipe, dopo di che avvio haikuporter -S ./QuickApp-1.0.recipe. Vengono controllate le dipendenze per tutti i pacchetti nel repository haikuports, il che richiede un po' di tempo. Vado a prendere un caffè.

Perché questa verifica dovrebbe avvenire sulla mia macchina locale e non centralmente su un server una volta per tutti?

Secondo mr. waddlesplash:

Con il fatto che è possibile sovrascrivere qualsiasi file nel repository 😉 Si può ottimizzare un po' calcolando le informazioni necessarie nel momento in cui servono, poiché le ultime modifiche apportate sono abbastanza rare.

~/QtQuickApp> haikuporter QtQuickApp-1.0.recipe
Controllando se ci sono aggiornamenti delle informazioni sulle dipendenze ...
Cercando informazioni sulle dipendenze obsolete ...
Errore: QtQuickApp non trovato nel repository

Si scopre che non esiste un normale file di ricetta, che contenga il codice sorgente della tua applicazione. Deve essere mantenuto in un repository nel formato HaikuPorts.

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

Questo fatto rende la compilazione più ingombrante. Non mi piace molto, ma penso che sia necessario affinché, alla fine, tutto il software open source appaia in HaikuPorts.

Ricevo quanto segue:

~\/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe\nControllando se è necessario aggiornare le informazioni sulle dipendenze ...\n        aggiornando le informazioni sulle dipendenze di QtQuickApp-1.0\nCerco informazioni sulle dipendenze obsolete ...\nErrore: QtQuickApp-1.0.recipe non trovato nell'albero.

Cosa c'è che non va? Dopo aver letto irc faccio:

~\/QtQuickApp> haikuporter -S QtQuickApp\nControllando se è necessario aggiornare le informazioni sulle dipendenze ...\n        aggiornando le informazioni sulle dipendenze di QtQuickApp-1.0\nCerco informazioni sulle dipendenze obsolete ...\n----------------------------------------------------------------------\napp-misc::QtQuickApp-1.0\n        \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe\n----------------------------------------------------------------------Scaricamento: https:\/\/github.com\/probonopd\/QtQuickApp.git ...\n--2019-07-14 16:12:44--  https:\/\/github.com\/probonopd\/QtQuickApp.git\nRisoluzione di github.com... 140.82.118.3\nConnessione a github.com|140.82.118.3|:443... connesso.\nRichiesta HTTP inviata, attesa della risposta... 301 Moved Permanently\nPosizione: https:\/\/github.com\/probonopd\/QtQuickApp [seguendo]\n--2019-07-14 16:12:45--  https:\/\/github.com\/probonopd\/QtQuickApp\nRiutilizzando la connessione esistente a github.com:443.\nRichiesta HTTP inviata, attesa della risposta... 200 OK\nLunghezza: non specificata [text\/html]\nSalvataggio in: ‘\/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’ salvato [90094]\nConvalida del checksum di QtQuickApp.git\nAvviso: ----- TEMPLATO DEL CHECKSUM -----\nAvviso: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"\nAvviso: -----------------------------\nErrore: Nessun checksum trovato nella ricetta!

È sorto un interessante interrogativo. Se aggiungo un checksum alla ricetta, corrisponderà all'ultimo commit git per l'integrazione continua? (Lo sviluppatore conferma: «Non uscirà nulla. Le ricette sono progettate per essere relativamente stabili»).

Per divertimento lo aggiungono alla ricetta:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Ancora non va bene:

~\/QtQuickApp> haikuporter -S QtQuickApp\nControllando se è necessario aggiornare le informazioni sulle dipendenze ...\n        aggiornando le informazioni sulle dipendenze di QtQuickApp-1.0\nCerco informazioni sulle dipendenze obsolete ...\n----------------------------------------------------------------------\napp-misc::QtQuickApp-1.0\n        \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe\n----------------------------------------------------------------------\nSaltando il download della sorgente per QtQuickApp.git\nConvalida del checksum di QtQuickApp.git\nEstrazione della sorgente di QtQuickApp.git\nErrore: Tipo di archivio non riconosciuto nel file \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git

Che gli prende? È un repository git, il codice è già lì, non c'è niente da decomprimere. Dal mio punto di vista, lo strumento dovrebbe essere abbastanza intelligente da non dover cercare un decompilatore se ha un url di GitHub.

Forse funzionerà uri git://

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

Ora si lamenta così:

Downloading: git://github.com/probonopd/QtQuickApp.git ...
Error: Il download da fonti non sicure è disabilitato in haikuports.conf!

Hmm, perché deve essere così complicato, perché non può semplicemente "funzionare"? Dopotutto, non è così raro ricavare qualcosa da GitHub. Non parliamo degli strumenti che funzionano immediatamente, senza necessità di configurazioni, o come lo chiamo io "grattacapi".

Forse funzionerà così:

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

No. Ricevo ancora quell'orribile errore e faccio, come descritto qui

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

Avanzo un po' più lontano, ma perché mi sta gridando (GitHub non è sicuro!) e sta ancora cercando di decomprimere qualcosa.

Secondo mr. waddlesplash:

Beh, la ragione è stata il desiderio di controllare l'integrità dei dati ricevuti per la costruzione. Una delle opzioni è il controllo della somma di controllo dell'archivio, ma si possono anche hashare file singoli, cosa che non verrà implementata, poiché richiede molto più tempo. Di conseguenza, si ha una "insicurezza" in git e in altri VCS. Probabilmente sarà sempre così, poiché creare un archivio su GitHub è piuttosto facile e spesso più veloce. E forse in futuro, il messaggio d'errore non sarà così stridente... (non eseguiamo più fusioni di tali ricette in HaikuPorts).

~ /QtQuickApp> haikuporter -S QtQuickApp
Controllando se ci sono informazioni sulle dipendenze da aggiornare ...
Cercando informazioni sulle dipendenze obsolete ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Downloading: git+https://github.com/probonopd/QtQuickApp.git ...
Warning: LE FONTI NON SICURE SONO CATTIVE E NON DOVREBBERO ESSERE UTILIZZATE IN PRODUZIONE
Warning: SI PREGA DI PASSARE A UN DOWNLOAD DI ARCHIVI STATICI CON SOMMA DI CONTROLLO IL PRIMA POSSIBILE!
Clonando nel repository vuoto '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
Decomprimendo la fonte di QtQuickApp.git
tar: /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0: Impossibile aprire: Nessun file o directory di questo tipo
tar: L'errore non è recuperabile: uscita ora
Il comando 'git archive HEAD | tar -x -C " /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0"' ha restituito uno stato di uscita non zero 2

Per vecchia abitudine, vado a chiedere alle persone gentili sul canale #haiku nella rete irc.freenode.net. E dove sarei senza di loro? Dopo un suggerimento ho capito che devo usare:

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

Bene, ora è chiaro cosa fa: scarica un archivio con il codice sorgente di una specifica revisione. È stupido, a mio avviso, e non è esattamente ciò che desideravo, ovvero scaricare l'ultima revisione dal ramo master.

Uno degli sviluppatori ha spiegato così:

Abbiamo il nostro CI, quindi tutto ciò che viene messo nel repository haikuports sarà impacchettato per tutti gli utenti, e non vogliamo rischiare raccogliendo e fornendo 'tutte le ultime versioni in upstream'.

Ho capito! Comunque, è venuto fuori questo:

in attesa dell'attivazione del pacchetto di build QtQuickApp-1.0-1
in attesa dell'attivazione del pacchetto di build QtQuickApp-1.0-1
in attesa dell'attivazione del pacchetto di build QtQuickApp-1.0-1
in attesa dell'attivazione del pacchetto di build QtQuickApp-1.0-1
in attesa dell'attivazione del pacchetto di build QtQuickApp-1.0-1
(...)

Continua a ripetersi all'infinito. Apparentemente, è un bug (c'è una segnalazione? Non l'ho trovata).

C haikuporter e il repository haikuports Non si percepisce un livello di 'funzionalità semplice', ma come sviluppatore, alcune cose nel lavorare con Haiku mi piacciono. Per la maggior parte sembra un Open Build Service: un insieme di strumenti per costruire pacchetti Linux: estremamente potente, con un approccio sistemico, ma eccessivo per la mia piccola applicazione di livello 'hello world'.

Ancora, secondo il signor waddlesplash:

Infatti, HaikuPorter è molto rigoroso di default (inoltre ci sono la modalità lint e la modalità rigorosa, che lo rendono ancora più severo!), ma solo perché crea pacchetti che funzioneranno, e non semplicemente per creare pacchetti. Ecco perché si lamenta delle dipendenze non dichiarate, delle librerie non importate correttamente, delle versioni errate, ecc. L'obiettivo è catturare tutti i problemi, comprese le future, prima che l'utente ne venga a conoscenza (ecco perché non siamo riusciti a installare avrdude, poiché nella ricetta era effettivamente dichiarata una dipendenza). Le librerie non sono semplicemente pacchetti separati e nemmeno versioni specifiche di SO. HaikuPorter monitora il rispetto di tutto ciò nelle ricette stesse, per evitare errori durante l'esecuzione.

In linea di principio, un tale livello di severità è giustificato nella creazione di un sistema operativo, ma mi sembra eccessivo per un'applicazione 'hello world'. Ho deciso di provare qualcos'altro.

Creazione di applicazioni nel formato hpkg, utilizzando il comando 'package create'

Forse, questo una semplice guida potrebbe adattarsi meglio a me?

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

summary "Applicazione demo QtQuick"
description "QtQuickApp è un'applicazione demo QtQuick per testare il porting e l'imballaggio di 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# Vedi qui sotto se desideri che l'applicazione
# appaia anche nel menu

Inaspettatamente veloce, inaspettatamente semplice, inaspettatamente efficace. Proprio come piace a me, straordinario!

Installazione — cosa e dove?

Ho spostato il file QtQuickApp.hpkg in ~/.config/packages, utilizzando il file manager, dopodiché QtQuickApp è magicamente apparso in ~/.config/apps.
Ancora una volta inaspettatamente veloce, semplice ed efficace. Straordinario, incredibile!

Ma... (come può mancare?)

L'applicazione è ancora assente nell'elenco del menu delle applicazioni e in QuickLaunch. Penso di sapere già come risolvere. Nel file manager sposto QtQuickApp.hpkg da ~/.config/packages in /system/packages.

No, è ancora assente. A quanto pare, ho (bene, e le istruzioni) trascurato qualcosa.

Esaminando la scheda "Contents" in HaikuDepot per alcune altre applicazioni, ho visto che ci sono file del tipo /data/mimedb/application/x-vnd... il che è ancora più significativo, /data/deskbar/menu/Applications/….

Beh, e cosa dovrei mettere lì dentro? Vediamo...

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

Sono sicuro che questo trucco funzionerà, ma rimangono domande: a cosa serve, a cosa serve? A mio avviso, distrugge l'impressione generale che il sistema sia così raffinato.

Come spiegato da mr. waddlesplash:

A volte ci sono applicazioni necessarie ad altre applicazioni, ma non nel menu. Ad esempio, LegacyPackageInstaller nel tuo screenshot, che gestisce gli archivi .pkg in formato BeOS. Vorremmo che gli utenti le installassero, ma la loro presenza nel menu porterebbe a confusione.

Per qualche motivo ho l'impressione che ci sia una soluzione più semplice, come Hidden=true nei file .desktop su Linux. Perché non fare in modo che le informazioni "nascoste" siano una risorsa e un attributo del file system?

Ciò che è particolarmente poco raffinato è il nome (di una certa) applicazione che mostra il menu, deskbar, rigidamente legato nel percorso.

mr. waddlesplash chiarisce a riguardo:

"Deskbar" in questo caso dovrebbe essere inteso come un termine generico (approssimativamente come "taskbar", che si riferisce sia a un'applicazione Windows che a un concetto generale). E poiché è deskbar, e non "Deskbar", questo può essere compreso in modo simile.

2 directory "quasi identiche" con applicazioni in esse

Perché ci sono 2 cataloghi con le applicazioni, e perché in uno c'è la mia QtQuickApplication e nell'altro no? (Non è infatti uno solo di sistema, ma l'altro è utente, il che per me sarebbe chiaro).
Sono davvero confuso e penso che sarebbe necessario unificare questa situazione.

commento mr. waddlesplash

Nel catalogo Apps ci sono applicazioni che non sono necessarie nel menu. Ma è davvero necessario migliorare la situazione del menu, renderlo più configurabile.

Richiesta, o questo non accadrà 😉

Mi sono chiesto: è così necessario posizionare le applicazioni in /system/apps, se non è desiderabile che gli utenti le vedano lì. Forse sarebbe meglio posizionarle altrove, dove l'utente non le incontrerebbe? Proprio come in Mac OS X, dove il contenuto dei pacchetti .app, che non dovrebbe essere visibile all'utente in /Applications, è nascosto nelle profondità /System/Library/…«`.

E riguardo alle dipendenze?

Penso che sia importante indicare le dipendenze, giusto? Si può considerare Qt parte fondamentale dell'installazione predefinita di Haiku? No! Qt non è installato per default. Può il programma di creazione pacchetti determinare automaticamente le dipendenze controllando i file ELF? Mi è stato detto che HaikuPorter fa davvero così, ma pacchetto no. Questo perché è semplicemente un "creatore di pacchetti" che da solo crea file hpkg.

Vale la pena rendere Haiku più sofisticato, introducendo una politica in base alla quale un pacchetto non dovrebbe avere dipendenze da pacchetti non inclusi in haikuports? (Мне бы так хотелось, поскольку подобная политика значительно облегчает задачу — система смогла бы автоматически разрешить зависимости каждого пакета, загружаемого откуда угодно, без возни с дополнительными источниками пакетов).

mr. waddlesplash chiarisce:

Non vorremmo limitare eccessivamente la libertà degli sviluppatori, perché è ovvio che se CompanyX desidera supportare il proprio set di software con dipendenze (e quindi un proprio repository) - è completamente libera di farlo.

In tal caso, forse sarebbe meglio consigliare di evitare ai pacchetti di terze parti dipendenze da qualsiasi cosa non rientri in haikuports, confezionando totalmente tutto il necessario con l'applicazione. Ma, penso, questo è un argomento per un articolo futuro in questa serie. [L'autore allude a AppImage? — nota del traduttore]

Aggiungere un'icona all'applicazione

E se volessi aggiungere alle risorse della mia applicazione appena creata una delle graziose icone incorporate? Si rivela essere un argomento affascinante, quindi ne faremo il tema del prossimo articolo.

Come organizzare una build continua delle applicazioni?

Immaginate un progetto simile a Inkscape (sì, sono a conoscenza del fatto che non è ancora disponibile in Haiku, ma è comodo per spiegarlo). Hanno un repository di codice sorgente. https://gitlab.com/inkscape/inkscape.
Ogni volta che qualcuno registra le proprie modifiche nel repository, vengono avviati i pipeline di build, dopodiché le modifiche vengono testate automaticamente, composte e l'applicazione viene impacchettata in diversi formati, inclusi AppImage per Linux (un pacchetto autonomo dell'applicazione che può essere scaricato per il test locale indipendentemente da ciò che potrebbe o meno essere installato nel sistema. [lo sapevo! — nota del traduttore]). Allo stesso modo, tutto avviene ad ogni richiesta di fusione dei rami, quindi è possibile scaricare l'applicazione compilata dal codice proposto nella richiesta di fusione anche prima della fusione.

Le richieste di fusione con stati di build e la possibilità di scaricare binari compilati nel caso di una build riuscita (contrassegnata in verde).

La build viene avviata nei contenitori Docker. GitLab offre runner gratuiti su Linux, e penso anche che sia possibile collegare runner propri (a proposito, non riesco a immaginare come possa funzionare per sistemi come Haiku, che so non avere Docker o un'alternativa, ma nemmeno FreeBSD ha Docker, quindi questo problema non è unico per Haiku).

In un mondo ideale, la build delle applicazioni per Haiku potrebbe essere eseguita all'interno di un contenitore Docker per Linux. In questo modo, la build per Haiku potrebbe essere integrata nei pipeline esistenti. Esistono cross-compilatori? O è necessario emulare tutto Haiku all'interno di un contenitore Docker, utilizzando qualcosa come QEMU/KVM (a condizione che funzioni in questo modo all'interno di Docker)? A proposito, molti progetti utilizzano principi simili. Per esempio, Scribus fa così — è già disponibile per Haiku. Un giorno arriverà il momento in cui potrò inviare tali richieste di fusione in altri progetti, per aggiungere supporto per Haiku.

Uno degli sviluppatori spiega:

Per altri progetti che desiderano creare pacchetti autonomamente, è supportato il metodo standard CMake/CPack. Altri sistemi di build potrebbero essere supportati se si chiama direttamente il programma di costruzione del pacchetto, il che è utile se le persone sono interessate. L'esperienza dimostra: fino ad ora non ci sono stati particolari interessi, quindi haikuporter ha funzionato come ci era comodo, ma alla fine entrambi i metodi devono funzionare insieme. Dobbiamo fornire un insieme di strumenti per la costruzione incrociata del software da Linux o da qualsiasi altro sistema operativo server (Haiku non è progettato per funzionare su server).

Applaudo in piedi. Gli utenti normali di Linux si sobbarcano tutto questo carico aggiuntivo e bagaglio (sicurezza, controllo rigoroso, ecc.) necessari a un sistema operativo server, ma non a uno personale. Pertanto, sono pienamente d'accordo che la possibilità di costruire applicazioni per Haiku su Linux sia la strada giusta.

Conclusione

Il porting di applicazioni POSIX su Haiku è possibile, ma potrebbe richiedere più risorse rispetto a una ricostruzione ordinaria. Sicuramente mi sarei bloccato su questo a lungo, se non fosse stato per l'aiuto delle persone nel canale #haiku sulla rete irc.freenode.net. Ma anche loro non sempre vedevano subito cosa non andava.

Le applicazioni scritte in Qt sono una leggera eccezione. Ho creato una semplice applicazione dimostrativa senza particolari problemi.

La costruzione di un pacchetto per semplici applicazioni è anch'essa abbastanza facile, ma solo per quelle "pubblicate in modalità tradizionale", cioè quelle che hanno archivi di codice sorgente versionati, destinati a essere supportati in haikuports. Per la costruzione continua (costruzione a ogni commit) da GitHub, tutto è relativamente complicato. Qui Haiku si avvicina di più a una distribuzione Linux che al risultato su Mac, dove premendo il pulsante "Build" in XCode si ottiene un pacchetto .app, pronto per essere inserito nell'immagine del disco .dmg, preparato per il caricamento sul mio sito.
La costruzione continua di applicazioni basate su sistemi operativi "server", ad esempio Linux, diventerà probabilmente possibile se ci sarà domanda da parte degli sviluppatori, ma al momento il progetto Haiku ha altre priorità più urgenti.

Provate voi stessi! Infatti, il progetto Haiku offre immagini da scaricare su DVD o USB, generate quotidianamente. Per installare, basta scaricare l'immagine e scriverla su una chiavetta usando Etcher

Hai domande? Ti invitiamo nel canale telegram in lingua russa telegram-канал.

Panoramica degli errori: Come spararsi un colpo in C e C++. Raccolta di ricette Haiku OS

Da autore traduzione: questo è il quinto articolo di un ciclo su Haiku.

Elenco degli articoli: La prima Secondo Terzo Quarto

Fonte: habr.com