🥇Il mio quinto giorno con Haiku: portiamo alcuni programmi

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

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

Non molto tempo Ho scoperto Haiku, un sistema operativo per PC sorprendentemente buono.
Oggi imparerò come portare nuovi programmi su questo sistema operativo. L'obiettivo principale è la descrizione della prima esperienza di passaggio ad Haiku dal punto di vista di uno sviluppatore Linux. Mi scuso per eventuali errori stupidi che ho commesso lungo il percorso, poiché non è passata nemmeno una settimana da quando ho scaricato Haiku per la prima volta.

Voglio raggiungere tre obiettivi:

Porta una semplice applicazione CLI
Porta un'applicazione dalla GUI a Qt
Quindi impacchettali nel formato hpkg (visto che sto ancora pensando di adattare AppDir e AppImage per Haiku...)

Iniziamo. Nelle sezioni la documentazione и sviluppoe così dentro wiki da HaikuPorts ho trovato la giusta direzione. C'è anche un libro PDF online BeOS: porting di un'applicazione Unix.
467 pagine - e questo è del 1997! È spaventoso guardarsi dentro, ma spero per il meglio. Le parole dello sviluppatore sono incoraggianti: "c'è voluto molto tempo perché BeOS non era conforme a POSIX", ma Haiku "per la maggior parte" è già così.

Porting di una semplice applicazione CLI

Il primo pensiero è stato quello di trasferire l'applicazione avrdude, ma, come si è scoperto, questo è già ho fatto tanto tempo fa.

Primo tentativo: niente da guardare

Quello che non riesco a capire è già questo Le app sono state trasferite su Haiku da oltre 10 anni - nonostante il fatto che il sistema operativo stesso non sia ancora nemmeno alla versione 1.0.

Secondo tentativo: è necessario riscrivere

Quindi userò ptouch-770, CLI per il controllo della stampante Brother P-Touch 770 che utilizzo per stampare le etichette.
Ci stampo sopra varie etichette e potresti averlo già visto nell'articolo precedente. Un po' prima ho scritto un piccolo programma wrapper GUI in Python (visto che è in Gtk+, dovrà essere riscritto, e questo è un buon motivo per imparare).

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

Il gestore dei pacchetti Haiku conosce librerie e comandi, quindi se ricevo il messaggio "impossibile trovare libintl" durante l'esecuzione configure - Mi lancio e basta pkgman install devel:libintl e il pacchetto richiesto verrà trovato. Allo stesso modo pkgman install cmd:rsync. Bene, ecc.

Tranne quando questo non funziona:

/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

Forse udev è troppo basato su Linux e quindi non esiste per Haiku. Ciò significa che devo modificare il codice sorgente che sto cercando di compilare.
Eh, non puoi saltare sopra la testa e non so nemmeno da dove cominciare.

Terzo tentativo

Sarebbe bello averlo tmate per Haiku, consentirei agli sviluppatori di Haiku di connettersi alla mia sessione terminale, nel caso qualcosa vada storto. Le istruzioni sono abbastanza semplici:

./autogen.sh
./configure
make
make install

Sembra bello, quindi perché non provarlo 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.
È stato trovato qualcosa che mi ha dato un suggerimento per una query più competente:

/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

Ancora una volta sono andato su HaikuDepot e, ovviamente, l'ho trovato devel:msgpack_c_cpp_devel. Quali sono questi 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

A questo punto, mi sono reso conto che il porting di un programma su Haiku richiede molte più conoscenze di quelle necessarie per una semplice ricostruzione.
Ho parlato con i simpatici sviluppatori di Haiku, ho scoperto che c'è un bug in msgpack e dopo pochi minuti vedo una patch in HaikuPorts. Posso vedere con i miei occhi come è stato corretto il pacchetto andando qui (buildslave - macchine virtuali).

Creazione del msgpack corretto su buildmaster

Nel frattempo invio una patch all'upstream per aggiungere il supporto Haiku a msgpack.

Cinque minuti dopo, il 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. Ho detto questo?!

Torno al problema iniziale:

/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

Ora sembra che msgpack non sia colpevole. sto commentando IMAXLABEL в tty.c come segue:

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

Il risultato:

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.

Bene, ci risiamo... A proposito:

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

Sig. waddlesplash ti dice 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 postato config.log.

Mi hanno spiegato che c'è qualcos'altro in libnetwork oltre a libresolv su Haiku. Apparentemente il codice deve essere ulteriormente modificato. Ho bisogno di pensare…

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

L’eterna 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

La stessa cosa, solo di profilo. Ho cercato su Google e trovato questo. Se aggiungi -lssp “a volte” aiuta, provo:

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

Oh! Sta iniziando! Ma…

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

Proverò a eseguire il debug archiviare qui:

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

“ID porto errato” è già come un biglietto da visita haiku. Forse qualcuno ha un'idea di cosa c'è che non va e come risolverlo? Se sì, aggiornerò l'articolo. Collegamento a GitHub.

Portare l'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!

Davvero semplice. Meno di un minuto!

Applicazioni di packaging in hpkg utilizzando haikuporter e haikuports.

Con cosa dovrei iniziare? Non esiste una documentazione semplice, vado sul canale #haiku su irc.freenode.net e sento:

Squadra package - un modo di basso livello per creare pacchetti. Nella maggior parte dei casi, PackageInfo le basta, come descritto nella sezione "Trasformarlo in un vero e proprio pacchetto .hpkg"
ho bisogno di fare qualcosa такое
Può usare hpkg-creatore (mi si blocca, segnalazione degli errori)

Non è chiaro cosa fare. Immagino di aver bisogno di una guida per principianti in stile Hello World, idealmente un video. Sarebbe bello avere anche una comoda introduzione a HaikuPorter, come avviene in GNU hello.

Sto leggendo quanto segue:

haikuporter è uno strumento per creare progetti di pacchetti comuni per Haiku. Utilizza il repository HaikuPorts come base per tutti i pacchetti. Le ricette Haikuporter vengono utilizzate per creare pacchetti.

Inoltre scopro che:

Non è necessario archiviare le ricette nella memoria HaikuPorts. Puoi creare un altro repository, inserirvi le ricette e quindi indirizzarvi haikuporter.

Proprio quello di cui ho bisogno, se non sto cercando un modo per rilasciare pubblicamente il pacchetto. Ma questo è 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/ # make it runnable from anywhere
cd haikuporter
cp haikuports-sample.conf /boot/home/config/settings/haikuports.conf
sed -i -e 's|/mydisk/haikuports|/boot/home/haikuports|g' /boot/home/config/settings/haikuports.conf

Scrivere una ricetta

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
}

Assemblare la ricetta

Salvo il file con il nome QtQuickApp-1.0.recipe, dopodiché lancio aikuporter -S ./QuickApp-1.0.recipe. Le dipendenze vengono controllate per tutti i pacchetti nel repository haikuports, il che richiede un po' di tempo. Vado a prendere un caffè.

Perché mai questo controllo dovrebbe essere eseguito sul mio computer locale e non centralmente sul server una volta per tutti?

Secondo il sig. waddlesplash:

Con questo puoi riscrivere qualsiasi file nel repository 😉 Puoi ottimizzarlo un po', calcolando le informazioni necessarie quando necessario, perché le ultime modifiche apportate sono piuttosto 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 repository

Si scopre che non esiste un normale file di ricette che contenga il codice sorgente della tua applicazione. È necessario conservarlo in un repository nel formato HaikuPorts.

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

Questo fatto rende il montaggio più macchinoso. Non mi piace particolarmente, ma penso che sia necessario affinché alla fine tutto il software open source appaia in HaikuPorts.

Ottengo quanto segue:

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

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

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

È sorta una domanda interessante. Se aggiungo un checksum alla ricetta, corrisponderà all'ultimo commit git per l'integrazione continua? (Lo sviluppatore conferma: "Non funzionerà. Le ricette sono progettate per essere relativamente stabili.")

Per divertimento aggiungete alla ricetta:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Non sono ancora soddisfatto:

~/QtQuickApp> haikuporter -S QtQuickApp
Checking if any dependency-infos need to be updated ...
        updating dependency infos of QtQuickApp-1.0
Looking for stale dependency-infos ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------
Skipping download of source for QtQuickApp.git
Validating checksum of QtQuickApp.git
Unpacking source of QtQuickApp.git
Error: Unrecognized archive type in file /boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git

Cosa sta facendo? Dopotutto, questo è un repository git, il codice è già lì direttamente, non c'è niente da decomprimere. Dal mio punto di vista, lo strumento dovrebbe essere abbastanza intelligente da non cercare un programma di decompressione se si trova sopra l'URL di GitHub.

Forse uri git:// funzionerà

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

Adesso si lamenta così:

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

Hmm, perché è tutto così complicato, perché non puoi "semplicemente lavorare"? Dopotutto, non è così raro creare qualcosa da GitHub. Che si tratti di strumenti che funzionano subito, senza necessità di configurazione o, come lo chiamo io, "disturbi".

Forse funzionerà così:

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

No. Ricevo ancora questo strano errore e lo faccio, come descritto qui

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

Mi sto muovendo un po' oltre, ma perché mi sta urlando contro (GitHub non è sicuro!) e sto ancora cercando di decomprimere qualcosa.

Secondo Sig. waddlesplash:

Ebbene sì, il motivo era il desiderio di verificare l'integrità dei dati ricevuti per l'assemblaggio. Una delle opzioni è verificare il checksum dell'archivio, ma puoi, ovviamente, eseguire l'hashing dei singoli file, cosa che non verrà implementata, perché ci vuole molto più tempo. La conseguenza di ciò è l’“insicurezza” di Git e di altri VCS. Molto probabilmente sarà sempre così, poiché creare un archivio su GitHub è abbastanza semplice e spesso più veloce. Bene, in futuro, forse il messaggio di errore non sarà così appariscente... (non uniamo più tali ricette in HaikuPorts).

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

Per vecchia abitudine, vado a chiedere alle brave persone sul canale #haiku sulla rete irc.freenode.net. E dove sarei senza di loro? Dopo il suggerimento, mi sono reso conto che avrei dovuto usare:

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

Ok, è diventato chiaro cosa fa: scarica un archivio con il codice sorgente di una determinata revisione. È stupido, dal mio punto di vista, e non esattamente quello che volevo, cioè scaricare l'ultima revisione dal ramo principale.

Uno degli sviluppatori lo ha spiegato in questo modo:

Abbiamo il nostro CI, quindi tutto ciò che viene inserito nel repository haikuports sarà assemblato per tutti gli utenti e non vogliamo rischiare di raccogliere e fornire "tutto nell'ultima versione a monte".

Inteso! In ogni caso, questo è quello che è successo:

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

Lo ripete all'infinito. Apparentemente si tratta di un errore (esiste un'applicazione? Non sono riuscito a trovarla).

С haikuporter e deposito haikuports Non ha la sensazione che "funziona e basta", ma come sviluppatore ci sono alcune cose che mi piacciono nel lavorare con Haiku. Per la maggior parte, è simile all'Open Build Service, un insieme di strumenti per creare build Linux: estremamente potente, con un approccio sistematico, ma eccessivo per la mia piccola applicazione "ciao mondo".

Ancora una volta, secondo il sig. waddlesplash:

In effetti, HaikuPorter è piuttosto rigido per impostazione predefinita (in più c'è una modalità lint e una modalità strict per renderlo ancora più rigido!), ma solo perché crea pacchetti che funzioneranno, anziché limitarsi a creare pacchetti. Ecco perché si lamenta di dipendenze non dichiarate, librerie non importate correttamente, versioni errate, ecc. L'obiettivo è individuare tutti i problemi, compresi quelli futuri, prima che l'utente se ne accorga (questo è il motivo per cui non è stato possibile installare avrdude, perché la dipendenza era effettivamente specificata nella ricetta). Le librerie non sono solo singoli pacchetti o anche versioni SO specifiche. HaikuPorter garantisce che tutto ciò venga rispettato nelle ricette stesse per evitare errori durante l'esecuzione.

In linea di principio, questo livello di rigore è giustificato quando si crea un sistema operativo, ma mi sembra non necessario per un'applicazione "ciao mondo". Ho deciso di provare qualcos'altro.

Creazione di applicazioni in formato hpkg utilizzando il comando "crea pacchetto".

forse questo Le semplici istruzioni funzioneranno meglio per me?

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

summary "Demo QtQuick application"
description "QtQuickApp is a demo QtQuick application for testing Haiku porting and packaging"

packager "probono"
vendor "probono"

copyrights "probono"
licenses "MIT"

provides {
  QtQuickApp = 1.0-1
}requires {
  qt5
}
EOFpackage create -b QtQuickApp.hpkg
package add QtQuickApp.hpkg apps# See below if you also want the application
# to appear in the menu

Inaspettatamente veloce, inaspettatamente semplice, inaspettatamente efficace. Esattamente come piace a me, fantastico!

Installazione: cosa e dove?

Spostato il file QtQuickApp.hpkg in ~/config/packagesutilizzando un file manager, dopo di che QtQuickApp è magicamente apparso in ~/config/apps.
Ancora una volta, inaspettatamente veloce, semplice ed efficace. Incredibile, incredibile!

Ma... (dove saremmo senza di loro!)

L'app non è ancora presente nell'elenco dei menu delle app e in QuickLaunch. Penso di sapere già come risolverlo. Nel file manager sposto QtQuickApp.hpkg da ~/config/packages a /system/packages.

No, ancora disperso. A quanto pare, io (beh, e le istruzioni) mi sono perso qualcosa.

Dopo aver esaminato la scheda "Contenuti" in HaikuDepot per alcune altre applicazioni, ho visto che ci sono file come /data/mimedb/application/x-vnd... ciò che è ancora più notevole è /data/deskbar/menu/Applications/….

Ebbene, cosa dovrei metterci? Dai...

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

Sono abbastanza sicuro che questo trucco funzionerà, ma le domande rimangono: perché è necessario, a cosa serve? Penso che questo rovini l'impressione generale che il sistema sia così sofisticato.

Come spiegato dal sig. waddlesplash:

A volte ci sono applicazioni di cui hanno bisogno altre applicazioni ma che non sono presenti nel menu. Ad esempio, LegacyPackageInstaller nel tuo screenshot, che elabora gli archivi .pkg in formato BeOS. Vorrei che gli utenti li installassero, ma la loro presenza nel menù creerà confusione.

Per qualche motivo mi sembra che esista una soluzione più semplice, ad esempio Hidden=true nei file .desktop su Linux. Perché non rendere le informazioni "nascoste" una risorsa e un attributo del file system?

Ciò che non è particolarmente sottile è il nome di (alcune) applicazioni che mostrano il menu, deskbar, rigidamente legati lungo il percorso.

Sig. waddlesplash spiega questo:

"Deskbar" in questo caso dovrebbe essere inteso come una sorta di termine generale (più o meno allo stesso modo di "taskbar", che si riferisce sia all'applicazione Windows che al concetto generale). Bene, da questo deskbar, non “Deskbar”, anche questo può essere inteso in modo simile.

2 directory "quasi identiche" con applicazioni al loro interno

Perché ci sono 2 directory con le applicazioni e anche perché la mia QtQuickApplication si trova in una, ma non nell'altra? (Dopo tutto, questo non è un sistema, ma un secondo utente, il che sarebbe comprensibile per me personalmente).
Sono davvero confuso e penso che questo dovrebbe essere unificato.

commento del sig. waddlesplash

Il catalogo delle app contiene applicazioni non necessarie nel menu. Ma la situazione del menù è davvero da migliorare, per renderlo più personalizzabile.

Applicazione, altrimenti non accadrà 😉

Mi sono chiesto: è davvero necessario ospitare le applicazioni /system/apps, se gli utenti li vedono lì, non è auspicabile. Forse sarebbe meglio posizionarli in un altro posto dove l'utente non li incontrerà? Proprio come avviene in Mac OS X, dove il contenuto dei pacchetti .app, che non dovrebbe essere visibile all'utente in /Applications, nascosto nelle profondità di /System/Library/…“`.

E le dipendenze?

Penso che valga la pena specificare le dipendenze in qualche modo, giusto? Qt può essere considerato una parte obbligatoria dell'installazione di Haiku per impostazione predefinita? No! Qt non è installato per impostazione predefinita. Un generatore di pacchetti può rilevare automaticamente le dipendenze controllando i file ELF? Mi è stato detto che HaikuPorter in realtà lo fa, ma package NO. Questo perché è solo un "costruttore di pacchetti" che crea solo file da solo hpkg.

Haiku dovrebbe essere reso più sofisticato aggiungendo una politica secondo la quale un pacchetto non dovrebbe avere dipendenze da pacchetti esterni a Haiku? haikuports? (Mi piacerebbe, perché una tale politica renderebbe le cose molto più semplici: il sistema sarebbe in grado di risolvere automaticamente le dipendenze di ogni pacchetto scaricato da qualsiasi luogo, senza perdere tempo con ulteriori fonti di pacchetti.)

Sig. waddlesplash spiega:

Non vorremmo limitare così tanto la libertà degli sviluppatori, perché è ovvio che se AziendaX vorrà supportare il proprio set di software con dipendenze (e quindi un repository), lo farà in totale libertà.

In tal caso, potrebbe valere la pena raccomandare che i pacchetti di terze parti evitino le dipendenze da tutto ciò che non è incluso in haikuports impacchettando completamente tutto ciò che è necessario con l'applicazione. Ma penso che questo sia un argomento per un futuro articolo di questa serie. [L'autore si sta dirigendo verso AppImage? - ca. traduttore]

Aggiunta dell'icona dell'applicazione

Cosa succede se voglio aggiungere una delle belle icone integrate alle risorse della mia applicazione appena creata? Si scopre che questo è un argomento straordinario, quindi costituirà la base per il prossimo articolo.

Come organizzare le build continue di applicazioni?

Immagina un progetto come Inkscape (sì, sono consapevole che non è ancora disponibile in Haiku, ma è conveniente visualizzarlo). Hanno un repository di codice sorgente https://gitlab.com/inkscape/inkscape.
Ogni volta che qualcuno apporta le proprie modifiche al repository, vengono avviate le pipeline di compilazione, dopodiché le modifiche vengono automaticamente testate, create e l'applicazione inserita in vari pacchetti, incluso AppImage per Linux (un pacchetto applicativo autonomo che può essere scaricato per test locali indipendentemente cosa può o non può essere installato sul sistema [Lo sapevo! - ca. traduttore]). La stessa cosa accade con ogni richiesta di fusione di rami, quindi puoi scaricare l'applicazione costruita dal codice proposto nella richiesta di fusione prima della fusione.

Unisci le richieste con gli stati della build e la possibilità di scaricare i file binari compilati se la build ha esito positivo (contrassegnati in verde)

La build viene eseguita in contenitori Docker. GitLab offre corridori gratuiti su Linux e penso che potrebbe essere possibile includere i propri corridori (a proposito, non vedo come funzionerebbe per sistemi come Haiku, che so non hanno Docker o equivalenti, ma anche per FreeBSD non esiste Docker, quindi questo problema non è esclusivo di Haiku).

Idealmente, le applicazioni Haiku possono essere create all'interno di un contenitore Docker per Linux. In questa situazione, l'assemblaggio per Haiku può essere introdotto nelle condutture esistenti. Esistono compilatori incrociati? Oppure dovrei emulare tutto Haiku all'interno di un contenitore Docker utilizzando qualcosa come QEMU/KVM (supponendo che funzionerà in questo modo all'interno di Docker)? A proposito, molti progetti utilizzano principi simili. Ad esempio, Scribus fa questo: è già disponibile per Haiku. Un giorno arriverà il giorno in cui potrò inviare tale Invia richieste ad altri progetti per aggiungere il supporto Haiku.

Uno degli sviluppatori spiega:

Per altri progetti che desiderano creare pacchetti da soli, è supportato il normale metodo CMake/CPack. Altri sistemi di compilazione possono essere supportati chiamando direttamente il programma di compilazione del pacchetto, il che va bene se le persone ne sono interessate. L'esperienza dimostra: finora non c'è stato molto interesse, quindi haikuporter ha funzionato nel modo più conveniente per noi, ma, alla fine, entrambi i metodi dovrebbero funzionare insieme. Dovremmo introdurre una serie di strumenti per il cross-building di software da Linux o qualsiasi altro sistema operativo server (Haiku non è progettato per funzionare sui server).

Faccio una standing ovation. Gli utenti Linux regolari portano con sé tutto questo carico aggiuntivo e bagaglio aggiuntivo (sicurezza, controllo rigoroso, ecc.) necessari per un sistema operativo server, ma non per uno personale. Quindi sono completamente d'accordo sul fatto che essere in grado di creare app Haiku su Linux sia la strada da percorrere.

conclusione

Il porting delle applicazioni POSIX su Haiku è possibile, ma potrebbe essere più costoso di una tipica ricostruzione. Sicuramente rimarrei bloccato per molto tempo se non fosse per l'aiuto delle persone del canale #haiku sulla rete irc.freenode.net. Ma anche loro non sempre capivano subito cosa c’era che non andava.

Le applicazioni scritte in Qt sono una facile eccezione. Ho messo insieme una semplice applicazione demo senza problemi.

Anche costruire un pacchetto per applicazioni semplici è abbastanza semplice, ma solo per quelle “rilasciate tradizionalmente”, cioè avere archivi di codice sorgente con versione destinati al supporto in haikuports. Per una build continua (build per ogni commit di modifiche) con GitHub, tutto sembra non essere così semplice. Qui Haiku sembra più una distribuzione Linux che il risultato su un Mac, dove quando fai clic sul pulsante "Crea" in XCode ottieni un pacchetto .app, pronto per essere inserito in un'immagine disco .dmg, preparato per il download sul mio sito web.
La creazione continua di applicazioni basate su un sistema operativo “server”, ad esempio Linux, diventerà molto probabilmente possibile se ci sarà richiesta da parte degli sviluppatori, ma al momento il progetto Haiku ha altri compiti più urgenti.

Prova tu stesso! Dopotutto, il progetto Haiku fornisce immagini per l'avvio da DVD o USB, generate quotidiano. Per installare, basta scaricare l'immagine e masterizzarla su un'unità flash USB utilizzando etcher

Hai domande? Ti invitiamo alla lingua russa canale telegramma.

Panoramica degli errori: Come spararsi ai piedi in C e C++. Raccolta di ricette del sistema operativo Haiku

Da l'autore traduzione: questo è il quinto articolo della serie sull'Haiku.

Elenco degli articoli: prima La seconda terzo quarto

Fonte: habr.com

Il mio quinto giorno con Haiku: portiamo qualche programma