TL;DR: Un principiante ha visto Haiku per la prima volta, prova a portare alcuni programmi dal mondo Linux.
Il mio primo programma portato per Haiku, impacchettato nel suo formato hpkg.
Ho scoperto Haiku, un sorprendentemente buono sistema operativo per PC.
Oggi imparerò a portare nuovi programmi su questo sistema operativo. L'accento principale sarà sulla descrizione della mia prima esperienza di transizione a Haiku dal punto di vista di uno sviluppatore Linux. Scusate per gli errori stupidi commessi lungo il percorso, dato che è passato meno di una settimana da quando ho caricato Haiku per la prima volta.
Voglio raggiungere tre obiettivi:
- Portare un'applicazione CLI semplice.
- Portare un'applicazione con GUI su Qt.
- Poi imballarle nel formato hpkg (dato che sto ancora pensando all'adattamento di AppDir e AppImage per Haiku…)
Iniziamo. Nelle sezioni e , così come in di HaikuPorts ho trovato la direzione giusta. C'è persino un libro online in formato PDF. .
467 pagine — e questo è dal 1997! È spaventoso dare un'occhiata dentro, ma spero nel meglio. Le parole del sviluppatore sono incoraggianti: «lento, perché BeOS non era POSIX-compliant», ma Haiku è «per la maggior parte» già così.
Portare un'applicazione CLI semplice
La prima idea è stata quella di portare l'applicazione , ma, come si è rivelato, è già da molto tempo.
Primo tentativo: non c'è nulla da vedere
Quello che non riesco a capire, è che già da — considerando che l'OS non ha nemmeno una versione 1.0.
Secondo tentativo: è necessario riscrivere
Quindi, userò , CLI per gestire la stampante Brother P-Touch 770, sulla quale stampo le etichette.
Stampo varie etichette su di essa e potresti averla già vista nel mio articolo precedente. Poco tempo fa ho scritto un piccolo programma wrapper con GUI in Python (dato che è su Gtk+ — dovrò riscriverlo, ed è una buona occasione per imparare).
La stampante per etichette Brother P-Touch 770. Funzionerà su Haiku?
Il gestore pacchetti di Haiku conosce le librerie e i comandi, quindi se ricevo un messaggio "can’t find libintl" all'avvio configure — basta eseguire pkgman install devel:libintl e il pacchetto necessario verrà trovato. Analogamente pkgman install cmd:rsync. E così via.
A parte i casi in cui 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 foundForse udev è troppo 'linuxy', quindi non esiste per Haiku. Questo significa che è necessario modificare il codice sorgente che sto cercando di compilare.
Eh, non si può andare oltre le proprie possibilità, e non so nemmeno da dove cominciare.
Terzo tentativo
Sarebbe utile avere tmate per Haiku, così 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 installSembra buono, 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 foundA questo punto apro HaikuDepot e cerco curses.
Qualcosa è apparso, che mi ha dato un suggerimento per una richiesta più appropriata:
/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 foundSono 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 1A questo punto ho capito che portare il programma su Haiku richiede molte più conoscenze di quelle necessarie per una semplice ricompilazione.
Ho parlato con i gentili sviluppatori di Haiku, e ho scoperto che c'è un bug in msgpack, e dopo qualche minuto vedo un patch in HaikuPorts. Osservo come il pacchetto sistemato (buildslave — macchine virtuali).
Compilazione del msgpack corretto su buildmaster
Nel frattempo invio il patch all'upstream. .
Cinque minuti dopo, msgpack aggiornato è già disponibile su 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 1Ora sembra che msgpack non sia colpevole. Commento IMAXLABEL in tty.c così:
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 creare il target '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... noindica 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 .
Mi è stato spiegato che per libresolv su Haiku c'è qualcos'altro in libnetwork. Evidentemente bisogna continuare a modificare il codice. Devo riflettere...
find . -type f -exec sed -i -e 's|lresolv|lnetwork|g' {} ;La questione di sempre: 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 foundLo stesso, solo che in profilo. Ho cercato su Google e . Se aggiungi -lssp a volte aiuta, provo:
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp"
(...)/Haiku/home/tmate> make
(...)/Haiku/home/tmate> ./tmateWow! Si avvia! Ma...
[tmate] errore di ricerca ssh.tmate.io. Riprovo tra 2 secondi (errore non recuperabile nella risoluzione dei nomi)Proverò a debuggarlo, :
/Haiku/home/tmate> strace -f ./tmate >log 2>&1«Bad port ID» - è già come un biglietto da visita . Magari qualcuno sa cosa non va e come sistemarlo? Se necessario, aggiornerò l'articolo. Link a .
Porting di un'app GUI su Qt.
Scelgo un'applicazione QML semplice.
/> 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 delle applicazioni in hpkg utilizzando haikuporter e haikuports.
Da dove iniziare? Non c'è una documentazione semplice, quindi vado sul canale #haiku di irc.freenode.net e sento:
- Team
pacchetto— un modo a basso livello per creare pacchetti. In gran parte, è sufficiente PackageInfo, come descritto nella sezione "Trasformarlo in un vero pacchetto .hpkg". - Devo fare qualcosa
- Puoi usare (mi si chiude, )
Non capisco cosa fare. Suppongo di aver bisogno di un manuale per principianti in stile "Ciao, Mondo!", idealmente un video. Sarebbe utile anche avere un'introduzione comoda a HaikuPorter, come è fatto in GNU hello.
Leggo il seguente:
haikuporterè uno strumento per creare progetti di pacchetti comuni per Haiku. Utilizza il repository HaikuPorts come base per tutti i pacchetti. Per creare pacchetti si usano le ricette di haikuporter.
Inoltre scopro che:
Non è necessario tenere le ricette nel repository HaikuPorts. Puoi creare un altro repository, inserire le ricette e quindi indicare a haikuporter di usarlo.
Proprio quello di cui ho bisogno — a meno che non 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 ovunque
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.confScrittura della ricetta
SUMMARY="Demo applicazione QtQuick"
DESCRIPTION="QtQuickApp è un'applicazione demo 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 eseguo haikuporter -S ./QuickApp-1.0.recipe. Verifico le dipendenze per tutti i pacchetti nel repository , il che richiede un po' di tempo. Vado a prendere un caffè.
E perché questa verifica dovrebbe essere effettuata sulla mia macchina locale invece che in modo centralizzato su un server una sola volta per tutti?
Secondo mr. waddlesplash:
Perché è possibile riscrivere qualsiasi file nel repository 😉 Si può un po' ottimizzare questo, calcolando le informazioni necessarie solo quando necessario, dato che le ultime modifiche effettuate sono piuttosto rare.
~/QtQuickApp> haikuporter QtQuickApp-1.0.recipe
Controllo se è necessario aggiornare le informazioni sulle dipendenze ...
Cerco informazioni sulle dipendenze obsolete ...
Errore: QtQuickApp non trovato nel repositoryNon esiste un file di ricetta normale che contenga il codice sorgente della tua applicazione. Deve essere mantenuto nel repository nel formato HaikuPorts.
~/QtQuickApp> mv QtQuickApp-1.0.recipe ../haikuports/app-misc/QtQuickApp/
~/QtQuickApp> ../haikuport
~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipeQuesto fatto rende la compilazione più ingombrante. Non mi piace molto, ma penso che sia necessario affinché, alla fine, tutto il software open source venga incluso in HaikuPorts.
Ricevo quanto segue:
~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe
Controllo se è necessario aggiornare le informazioni sulle dipendenze ...
aggiornamento delle informazioni sulle dipendenze di QtQuickApp-1.0
Cerco informazioni sulle dipendenze obsolete ...
Errore: QtQuickApp-1.0.recipe non trovato nell'albero.Cosa c'è di sbagliato? Dopo aver letto irc faccio:
~/QtQuickApp> haikuporter -S QtQuickApp
Controllo se è necessario aggiornare le informazioni sulle dipendenze ...
aggiornamento delle informazioni sulle dipendenze di QtQuickApp-1.0
Cercando informazioni sulle dipendenze obsolete ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
/boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Download: https://github.com/probonopd/QtQuickApp.git ...
--2019-07-14 16:12:44-- https://github.com/probonopd/QtQuickApp.git
Risoluzione di github.com... 140.82.118.3
Connessione a github.com|140.82.118.3|:443... connesso.
Richiesta HTTP inviata, attesa della risposta... 301 Moved Permanently
Posizione: https://github.com/probonopd/QtQuickApp [seguendo]
--2019-07-14 16:12:45-- https://github.com/probonopd/QtQuickApp
Riutilizzo della connessione esistente a github.com:443.
Richiesta HTTP inviata, attesa della risposta... 200 OK
Lunghezza: non specificata [text/html]
Salvataggio in: ‘/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’ salvato [90094]
Validazione del checksum di QtQuickApp.git
Attenzione: ----- TEMPLATO DI CHECKSUM -----
Attenzione: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"
Attenzione: -----------------------------
Errore: Nessun checksum trovato nella ricetta!È sorta una domanda interessante. Se aggiungo un checksum nella 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 si aggiunge alla ricetta:
CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"Ancora non è soddisfacente:
~/QtQuickApp> haikuporter -S QtQuickApp
Controllo se ci sono informazioni sulle dipendenze da aggiornare ...
aggiornando le informazioni sulle dipendenze di QtQuickApp-1.0
Cercando informazioni sulle dipendenze obsolete ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
/boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------
Salto il download della sorgente per QtQuickApp.git
Validando il checksum di QtQuickApp.git
Estraendo la sorgente di QtQuickApp.git
Errore: Tipo di archivio non riconosciuto nel file /boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.gitChe diavolo fa? È un repository git, il codice è già lì, non c'è nulla da estrarre. Dalla mia prospettiva, lo strumento dovrebbe essere abbastanza intelligente da non cercare un estrattore, se ha il link url con GitHub.
Forse uri git:// funzionerà
SOURCE_URI="git://github.com/probonopd/QtQuickApp.git"Ora si lamenta così:
Download: git://github.com/probonopd/QtQuickApp.git ...
Errore: Il download da fonti non sicure è disabilitato in haikuports.conf!Hmm, perché è tutto così complicato, perché non può «funzionare semplicemente»? Alla fine, non è così raro raccogliere qualcosa da GitHub. È tutta un'altra storia per gli strumenti che funzionano immediatamente, senza necessità di configurazione, o come lo chiamo io, «inconvenienti».
Forse funzionerà così:
SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"No. Continuo a ricevere questo strano errore e faccio,
sed -i -e 's|#ALLOW_UNSAFE_SOURCES|ALLOW_UNSAFE_SOURCES|g' /boot/home/config/settings/haikuports.confAvanzo un po' più in là, ma perché mi sta urlando contro (GitHub non è sicuro!) e continua a provare a decomprimere qualcosa.
Secondo :
Sì, la causa è stata il desiderio di controllare l'integrità dei dati ricevuti per la build. Una delle opzioni è controllare il checksum dell'archivio, ma si possono anche fare hash di singoli file, il che non verrà realizzato, poiché richiede molto più tempo. E questo è il motivo della "nonsicurezza" di git e di altri VCS. È probabile che sia sempre così, dato che creare un archivio su GitHub è abbastanza facile e spesso più veloce. E in futuro, forse, il messaggio di errore non sarà così allarmante... (non facciamo più merging di queste ricette in HaikuPorts).
~/QtQuickApp> haikuporter -S QtQuickApp
Controllo se è necessario aggiornare le informazioni sulle dipendenze ...
Cercando informazioni sulle dipendenze obsolete ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
/boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Scaricando: git+https://github.com/probonopd/QtQuickApp.git ...
Attenzione: LE SOURCES INSICURE SONO MALE E NON DOVREBBERO ESSERE UTILIZZATE IN PRODUZIONE
Attenzione: SI PREGA DI PASSARE A UN DOWNLOAD DI ARCHIVIO STATICO CON CHECKSUM IL PRIMA POSSIBILE!
Clonazione nel repository vuoto '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
Scompattando la sorgente 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 diverso da zero 2Per vecchia abitudine, vado a chiedere a delle brave persone sul canale #haiku nella rete irc.freenode.net. E dove sarei senza di loro? Dopo il suggerimento, ho capito che dovevo 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 l'archivio con il codice sorgente di una certa revisione. È sciocco, dal mio punto di vista, e non esattamente ciò che volevo, ovvero — scaricare l'ultima revisione dal ramo master.
Uno degli sviluppatori ha spiegato così:
Abbiamo il nostro CI, quindi tutto ciò che viene inserito nel repository haikuports sarà impacchettato per tutti gli utenti, e non vogliamo correre il rischio di compilare e fornire 'tutte le ultime versioni in upstream'.
Capito! In ogni caso, è venuto fuori questo:
in attesa che il pacchetto di build QtQuickApp-1.0-1 venga attivato
in attesa che il pacchetto di build QtQuickApp-1.0-1 venga attivato
in attesa che il pacchetto di build QtQuickApp-1.0-1 venga attivato
in attesa che il pacchetto di build QtQuickApp-1.0-1 venga attivato
in attesa che il pacchetto di build QtQuickApp-1.0-1 venga attivato
(...)Continua a ripetere così all'infinito. Sembrerebbe un errore (c'è già una segnalazione? Non l'ho trovata).
C haikuporter e repository non si sente il livello di 'funziona semplicemente', ma come sviluppatore, ci sono alcune cose nel lavorare con Haiku che mi piacciono. Per la maggior parte assomiglia a Open Build Service: un set di strumenti per costruire build Linux: estremamente potente, con un approccio sistematico, ma eccessivo per la mia piccola applicazione di 'hello world'.
Ancora una volta, secondo mr. waddlesplash:
In effetti, HaikuPorter è davvero rigoroso per impostazione predefinita (oltre ad avere la modalità lint e la modalità rigorosa che lo rendono ancora più severo!), ma solo perché crea pacchetti che funzioneranno, non semplicemente pacchetti casuali. Ecco perché si lamenta delle dipendenze non dichiarate, delle librerie non importate correttamente, delle versioni errate, e così via. L'obiettivo è catturare ogni singolo problema, comprese le questioni future, prima che l'utente ne sia a conoscenza (ecco perché non è stato possibile installare avrdude, in quanto nel ricetta era effettivamente presente una dipendenza). Le librerie non sono semplici pacchetti separati e nemmeno versioni specifiche di SO. HaikuPorter si assicura che tutto questo venga rispettato all'interno delle ricette per evitare errori durante l'esecuzione.
In linea di principio, questo 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, una semplice istruzione potrebbe andar meglio?
mkdir -p apps/
cp QtQuickApp apps/cat > .PackageInfo <<EOF
name QtQuickApp
version 1.0-1
architecture x86_64
summary "Demo QtQuick application"
description "QtQuickApp è un'applicazione demo di QtQuick per testare il porting e l'imballaggio su 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 sotto se vuoi che anche l'applicazione
# appaia nel menuInaspettatamente 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 gestore di file, dopo di che QtQuickApp è apparso magicamente in ~/config/apps.
Ancora una volta inaspettatamente veloce, semplice ed efficace. Straordinario, incredibile!
Ma… (come fare senza!)
L'applicazione è ancora assente nell'elenco delle applicazioni e in QuickLaunch. Penso di sapere già come risolvere il problema. Nel gestore di file sposto QtQuickApp.hpkg da ~/config/packages a /system/packages.
Niente da fare, è ancora assente. A quanto pare ho (beh, e le istruzioni) saltato qualcosa.
Esaminando la scheda "Contents" in HaikuDepot per alcune altre applicazioni, ho visto che ci sono file del tipo /data/mimedb/application/x-vnd... cosa ancora più notevole, /data/deskbar/menu/Applications/….
Beh, e cosa devo metterci dentro? Proviamo…
mkdir -p data/deskbar/menu/Applications/
( cd data/deskbar/menu/Applications ; ln -s ../../../../../apps/QtQuickApp . )
package add QtQuickApp.hpkg apps dataSono abbastanza sicuro che questo trucco funzionerà, ma ho alcune domande: a cosa serve, perché è necessario? Secondo me, distrugge l'impressione generale che il sistema sia così raffinato.
Come ha spiegato mr. waddlesplash:
A volte ci sono applicazioni necessarie ad altre applicazioni, ma non nel menu. Ad esempio, LegacyPackageInstaller nel tuo screenshot, che gestisce archivi .pkg in formato BeOS. Vorremmo che gli utenti potessero installarli, ma la loro presenza nel menu porterebbe confusione.
Mi sembra che ci sia 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 raffinato è il nome (di un certo) programma che mostra il menu, deskbar, fissato nel percorso.
mr. waddlesplash поясняет по этому поводу:
"Deskbar" in questo caso deve essere inteso come un termine generale (un po' come "taskbar", che si riferisce sia a un'applicazione Windows che a un concetto generale). Dato che è questo
deskbar, e non "Deskbar", può essere inteso in modo simile.
2 «quasi identici» cataloghi con le loro applicazioni
Perché ci sono 2 cataloghi di applicazioni, e perché in uno c'è la mia QtQuickApplication e nell'altro no? (Non è un sistema unico, ma un secondo catalogo utente, che personalmente mi sembrerebbe chiaro).
Sono davvero confuso e penso che sia necessario uniformare questo.
commento di mr. waddlesplash
Nel catalogo Apps ci sono applicazioni non necessarie nel menu. Ma la situazione con il menu deve davvero migliorare, rendendolo più personalizzabile.
Richiesta, oppure questo non accadrà 😉
Mi sono chiesto: è davvero necessario posizionare le applicazioni in /system/apps, se per gli utenti è indesiderato vederle lì? Forse sarebbe meglio metterle in un altro posto dove l'utente non le incontrerà? Proprio come fatto in Mac OS X, dove il contenuto dei pacchetti .app, che non dovrebbe essere visibile all'utente in /Applications, è nascosto nelle profondità /System/Library/…«`.
Cosa dire delle dipendenze?
Penso che sia opportuno indicare in qualche modo le dipendenze, vero? Possiamo considerare Qt una parte obbligatoria dell'installazione di Haiku di default? No! Qt non è installato di default. Può il programma di costruzione del pacchetto determinare automaticamente le dipendenze controllando i file ELF? Mi è stato detto che HaikuPorter fa proprio così, mentre pacchetto no. Tutto perché è semplicemente un "costruttore di pacchetti" che da solo crea file hpkg.
Vale la pena rendere Haiku più sofisticato, aggiungendo una politica secondo cui un pacchetto non dovrebbe avere dipendenze da pacchetti non inclusi in haikuports? (Мне бы так хотелось, поскольку подобная политика значительно облегчает задачу — система смогла бы автоматически разрешить зависимости каждого пакета, загружаемого откуда угодно, без возни с дополнительными источниками пакетов).
mr. waddlesplash spiega:
Non ci piacerebbe limitare così tanto la libertà degli sviluppatori, poiché è evidente che se CompanyX decidesse di supportare un proprio set di software con dipendenze (e quindi un proprio repository) — avrebbero tutto il diritto di farlo.
In tal caso, forse sarebbe opportuno raccomandare di evitare ai pacchetti esterni dipendenze da qualsiasi cosa non inclusa in haikuports, tramite l'imballaggio completo di tutto il necessario con l'applicazione. Ma, penso che sia un argomento per un futuro articolo di questa serie. [L'autore allude a AppImage? — nota del traduttore]
Aggiunta dell'icona dell'applicazione
E se volessi aggiungere una delle eleganti icone incorporate alle risorse della mia nuova applicazione? Si tratta di un argomento affascinante, quindi sarà il tema principale del prossimo articolo.
Come organizzare una build continua delle applicazioni?
Immagina un progetto simile a Inkscape (sì, so che attualmente non è presente in Haiku, ma è utile per spiegarlo). Hanno un repository di codice sorgente. https://gitlab.com/inkscape/inkscape.
Ogni volta che qualcuno registra le proprie modifiche nel repository, viene avviato un processo di build, dopo di che le modifiche vengono automaticamente testate, compilate e l'applicazione viene pacchettizzata in vari formati, incluso AppImage per Linux (un pacchetto autonomo dell'applicazione che può essere caricato per test locali indipendentemente da ciò che può o non può essere installato nel sistema). [lo sapevo! — nota del traduttore]). Lo stesso avviene ad ogni richiesta di unione dei rami, quindi è possibile scaricare l'applicazione costruita dal codice proposto nella richiesta di unione ancora prima dell'unione.
Le richieste di merge con stati di build e la possibilità di scaricare i binari costruiti in caso di build riuscita (contrassegnata in verde)
La build viene avviata in contenitori Docker. GitLab offre runner gratuiti su Linux, e penso sia possibile collegare runner propri (tra l'altro, non riesco a immaginare come questo possa funzionare per sistemi come Haiku, che so non avere Docker o un equivalente, ma anche FreeBSD non ha Docker, quindi questo problema non è unico per Haiku).
Idealmente, la build delle applicazioni per Haiku può essere effettuata all'interno di un contenitore Docker per Linux. In questo modo, la build per Haiku può essere integrata nei pipeline esistenti. Ci sono cross-compilatori? O è necessario emulare l'intero Haiku all'interno del contenitore Docker, utilizzando qualcosa come QEMU/KVM (a patto che funzioni all'interno di Docker)? Tra l'altro, molti progetti utilizzano principi simili. Ad esempio, Scribus lo fa — è già disponibile per Haiku. Arriverà un giorno in cui potrò inviare richieste di merge in altri progetti per aggiungere supporto per Haiku.
Uno degli sviluppatori spiega:
Per altri progetti che desiderano creare pacchetti in modo autonomo, è supportato il metodo CMake/CPack. Altri sistemi di build possono essere supportati se si chiama direttamente il programma di creazione del pacchetto, il che è utile se le persone sono interessate. L'esperienza dimostra: finora non c'è stato particolare interesse, quindi haikuporter ha funzionato come era comodo per noi, ma, alla fine, entrambi i metodi dovrebbero lavorare insieme. Dovremmo presentare un set di strumenti per la cross-compilazione di software da Linux o qualsiasi altro sistema operativo server (Haiku non è progettato per funzionare su server).
Applaudo in piedi. Gli utenti comuni di Linux si portano dietro tutto questo carico extra e il bagaglio aggiuntivo (sicurezza, controlli severi, ecc.) necessari per un sistema operativo server, non per uno personale. Pertanto, sono completamente d'accordo che la possibilità di creare applicazioni per Haiku su Linux sia la strada giusta.
Conclusione
Il porting delle applicazioni POSIX su Haiku è possibile, ma potrebbe richiedere più sforzi rispetto a una ricompilazione normale. Sicuramente mi sarei bloccato a lungo se non fosse stato per l'aiuto delle persone nel canale #haiku su irc.freenode.net. Tuttavia, anche loro non sempre riuscivano a vedere subito cosa non andasse.
Le applicazioni scritte in Qt sono un'eccezione leggera. Ho creato una semplice applicazione dimostrativa senza particolari problemi.
La creazione di pacchetti per applicazioni semplici è abbastanza facile, ma solo per quelle «rilasciate nel modo tradizionale», cioè che hanno archivi di codice sorgente versionati destinati a essere supportati in haikuports. Per la creazione continua (compilazione a ogni commit) con GitHub, le cose sembrano non essere così semplici. Qui Haiku si sente più simile a una distribuzione Linux che al risultato su Mac, dove premendo il pulsante 'Compila' 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 un sistema operativo 'server', come Linux, potrebbe diventare possibile se ci sarà una domanda da parte degli sviluppatori, ma attualmente il progetto Haiku ha altre priorità più urgenti.
Provatelo voi stessi! Infatti, il progetto Haiku fornisce immagini da scaricare su DVD o USB, generate . Per installarlo, basta scaricare l'immagine e scriverla su una chiavetta USB usando
Avete domande? Vi invitiamo a unirvi al nostro .
Panoramica sugli errori:
Da traduzione: questo è il quinto articolo di un ciclo su Haiku.
Elenco degli articoli:
Fonte: habr.com
