🥇El meu cinquè dia amb Haiku: portem alguns programes

TL; DR: Un novell va veure Haiku per primera vegada, intentant portar alguns programes del món Linux.

El meu primer programa portat Haiku, empaquetat en el seu format hpkg

Recentment Vaig descobrir Haiku, un sistema operatiu sorprenentment bo per a ordinadors.
Avui aprendré a portar nous programes a aquest sistema operatiu. El focus principal és una descripció de la primera experiència de canviar a Haiku des del punt de vista d'un desenvolupador de Linux. Demano disculpes pels errors estúpids que vaig cometre al llarg del camí, ja que no ha passat ni una setmana des que em vaig descarregar Haiku per primera vegada.

Vull aconseguir tres objectius:

Porta una aplicació CLI senzilla
Porta una aplicació de la GUI a Qt
A continuació, empaqueteu-los en format hpkg (ja que encara estic pensant a adaptar AppDir i AppImage per a Haiku...)

Comencem. En seccions documentació и desenvolupamentaixí com a wiki des de HaikuPorts vaig trobar la direcció correcta. Fins i tot hi ha un llibre PDF en línia BeOS: Portar una aplicació Unix.
467 pàgines - i això és del 1997! Fa por mirar dins, però espero que sigui el millor. Les paraules del desenvolupador són encoratjadores: "va trigar molt de temps perquè BeOS no era compatible amb POSIX", però Haiku "en la seva majoria" ja és així.

Portar una aplicació CLI senzilla

El primer pensament va ser portar l'aplicació avrdude, però, com va resultar, això ja és han fet fa molt de temps.

Primer intent: res a veure

El que no puc entendre ja és això Les aplicacions s'han portat a Haiku durant més de 10 anys - malgrat que el propi sistema operatiu encara no és la versió 1.0.

Segon intent: cal reescriure

Així que faré servir ptouch-770, CLI per controlar la impressora Brother P-Touch 770 que faig servir per imprimir etiquetes.
Hi imprimeixo diverses etiquetes, i potser ja ho heu vist a l'article anterior. Una mica abans, vaig escriure un petit programa d'embolcall de GUI en Python (com que és a Gtk+, s'haurà de reescriure, i aquesta és una bona raó per aprendre).

Impressora d'etiquetes Brother P-Touch 770. Funcionarà amb Haiku?

El gestor de paquets Haiku sap sobre biblioteques i ordres, així que si rebo un missatge "no trobo libintl" quan s'executa configure - Acabo de llançar pkgman install devel:libintl i es trobarà el paquet requerit. igualment pkgman install cmd:rsync. Bé, etc.

Excepte quan això no funciona:

/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

Potser udev està massa basat en Linux i, per tant, no existeix per a Haiku. El que significa que he d'editar el codi font que estic intentant compilar.
Eh, no pots saltar per sobre del teu cap, i no sé ni per on començar.

Tercer intent

Estaria bé tenir-ho tmate per a Haiku, aleshores permetria que els desenvolupadors de Haiku es connectessin a la meva sessió de terminal, per si alguna cosa va malament. Les instruccions són bastant senzilles:

./autogen.sh
./configure
make
make install

Té bona pinta, per què no provar-ho a 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

En aquest pas obro HaikuDepot i cerco curses.
S'ha trobat alguna cosa que em va donar una pista per a una consulta més competent:

/Haiku/home/tmate> pkgman install devel:libncurses
(...)
100% ncurses6_devel-6.1-1-x86_64.hpkg [835.62 KiB]
(...)./configure
(...)
checking for msgpack >= 1.1.0... no
configure: error: "msgpack >= 1.1.0 not found"/Haiku/home/tmate> pkgman install devel:msgpack
(...)
*** Failed to find a match for "devel:msgpack": Name not found/Haiku/home/tmate> pkgman install devel:libmsgpack
(...)
*** Failed to find a match for "devel:libmsgpack": Name not found

De nou vaig anar a HaikuDepot i, per descomptat, vaig trobar devel:msgpack_c_cpp_devel. Quins són aquests noms estranys?

/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

En aquest pas, em vaig adonar que portar un programa a Haiku requereix molt més coneixement del que es necessita per a una reconstrucció senzilla.
Vaig parlar amb els amigables desenvolupadors de Haiku, resulta que hi ha un error al msgpack i, al cap d'uns minuts, veig un pegat a HaikuPorts. Puc veure amb els meus propis ulls com el paquet corregit anant aquí (buildslave - màquines virtuals).

Construint el msgpack corregit a buildmaster

Entre temps, envio un pedaç a aigües amunt per afegir suport Haiku a msgpack.

Cinc minuts més tard, el msgpack actualitzat ja està disponible en 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.

Inesperadament bo. He dit això?!

Torno al problema original:

/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

Ara sembla que msgpack no té cap culpa. Estic comentant IMAXLABEL в tty.c així que:

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

Resultat:

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.

Bé, aquí tornem... Per cert:

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

Sr. waddlesplash us diu on cal excavar:

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

Aquí he publicat config.log.

Em van explicar que hi ha alguna cosa més a libnetwork a més de libresolv a Haiku. Pel que sembla, el codi s'ha d'editar més. Cal pensar…

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

L'eterna pregunta: què està passant?

/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

El mateix, només de perfil. Google i trobat això. Si afegeixes -lssp "De vegades" ajuda, intento:

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

Vaja! Està començant! Però…

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

Intentaré depurar fitxer aquí:

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

"ID de port incorrecte" ja és com una targeta de visita haiku. Potser algú té una idea de què passa i com solucionar-ho? Si és així, actualitzaré l'article. Enllaç a GitHub.

Portar l'aplicació GUI a Qt.

Trio una aplicació QML senzilla.

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

Realment senzill. Menys d'un minut!

Aplicacions d'embalatge en hpkg mitjançant haikuporter i haikuports.

Per què he de començar? No hi ha documentació senzilla, vaig al canal #haiku a irc.freenode.net i escolto:

Equip package - una forma de baix nivell de crear paquets. En la seva majoria, PackageInfo és suficient per a ella, tal com es descriu a la secció "Convertir-lo en un paquet .hpkg adequat"
Necessito fer alguna cosa такое
Es pot utilitzar hpkg-creador (em falla, informe d'errors)

No està clar què fer. Suposo que necessito una guia per a principiants d'estil Hello World, idealment un vídeo. Seria bo tenir també una introducció convenient a HaikuPorter, com es fa a GNU hello.

Estic llegint el següent:

haikuporter és una eina per crear projectes de paquets comuns per a Haiku. Utilitza el dipòsit HaikuPorts com a base per a tots els paquets. Les receptes d'Haikuporter s'utilitzen per crear paquets.

A més, descobreixo que:

No cal emmagatzemar receptes a l'emmagatzematge HaikuPorts. Podeu fer un altre repositori, posar-hi les receptes i després apuntar-hi haikuporter.

Just el que necessito, si no busco una manera de llançar públicament el paquet. Però aquest és un tema per a un altre post.

Instal·lació de haikuporter i haikuports

cd /boot/home/
git clone https://github.com/haikuports/haikuporter --depth=50
git clone https://github.com/haikuports/haikuports --depth=50
ln -s /boot/home/haikuporter/haikuporter /boot/home/config/non-packaged/bin/ # make it runnable from anywhere
cd haikuporter
cp haikuports-sample.conf /boot/home/config/settings/haikuports.conf
sed -i -e 's|/mydisk/haikuports|/boot/home/haikuports|g' /boot/home/config/settings/haikuports.conf

Escriure una recepta

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
}

Muntatge de la recepta

Deso el fitxer sota el nom QtQuickApp-1.0.recipe, després de la qual llanço aikuporter -S ./QuickApp-1.0.recipe. Les dependències es comproven per a tots els paquets del repositori haikuports, que porta una mica de temps. Vaig a prendre un cafè.

Per què s'ha de fer aquesta comprovació a la meva màquina local i no centralment al servidor una vegada per a tothom?

Segons el Sr. waddlesplash:

Amb tal que pots reescriure qualsevol fitxer del repositori 😉 Pots optimitzar-ho una mica, calculant la informació necessària quan calgui, perquè els últims canvis realitzats són força rars.

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

Resulta que no existeix un fitxer de receptes normal que contingui el codi font de la vostra aplicació. Heu de mantenir-lo en un dipòsit en format HaikuPorts.

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

Aquest fet fa que el muntatge sigui més feixuc. No m'agrada especialment, però crec que és necessari perquè eventualment tot el programari de codi obert aparegui a HaikuPorts.

Rebo el següent:

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

Que passa? Després de llegir irc faig:

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

Ha sorgit una pregunta interessant. Si afegeixo una suma de comprovació a la recepta, coincidirà amb l'última confirmació de git per a la integració contínua? (El desenvolupador confirma: "No funcionarà. Les receptes estan dissenyades per ser relativament estables.")

Per diversió, afegiu a la recepta:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Encara no està satisfet:

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

Què està fent? Al cap i a la fi, aquest és un repositori git, el codi ja hi és directament, no hi ha res per desempaquetar. Des del meu punt de vista, l'eina hauria de ser prou intel·ligent per no buscar un desempaquetat si es troba per sobre de l'url de GitHub.

Potser uri git:// funcionarà

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

Ara es queixa així:

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

Hmm, per què tot és tan complicat, per què no pots "treballar"? Després de tot, no és tan estrany crear alguna cosa des de GitHub. Tant si es tracta d'eines que funcionen de seguida, sense necessitat d'instal·lar-les, o com jo l'anomeno "inquietud".

Potser funcionarà així:

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

No. Encara tinc aquest error estrany i ho faig, tal com es descriu aquí

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

Vaig una mica més enllà, però per què em crida (GitHub no és segur!) i encara intento desempaquetar alguna cosa.

Segons Sr. waddlesplash:

Doncs sí, el motiu va ser la voluntat de comprovar la integritat de les dades rebudes per al seu muntatge. Una de les opcions és verificar la suma de comprovació de l'arxiu, però, per descomptat, podeu fer hash fitxers individuals, que no s'implementaran, perquè triga molt més. La conseqüència d'això és la "inseguretat" de git i altres VCS. És probable que això sigui sempre així, ja que crear un arxiu a GitHub és bastant fàcil i sovint més ràpid. Bé, en el futur, potser el missatge d'error no serà tan cridaner... (ja no fusionem aquestes receptes a 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 vell costum, vaig a preguntar a la gent bona al canal #haiku de la xarxa irc.freenode.net. I on seria jo sense ells? Després de la pista, em vaig adonar que hauria d'utilitzar:

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

D'acord, va quedar clar què fa: baixa un arxiu amb el codi font d'una determinada revisió. És estúpid, des del meu punt de vista, i no és exactament el que volia, és a dir, descarregar la darrera revisió de la branca mestra.

Un dels desenvolupadors ho va explicar d'aquesta manera:

Tenim el nostre propi CI, de manera que tot el que es col·loqui al dipòsit d'haikuports s'empaquetarà per a tots els usuaris, i no volem arriscar-nos a recollir i lliurar "tot el que es troba a l'última versió aigües amunt".

Entès! En tot cas, això és el que va passar:

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

Això ho repeteix a l'infinit. Pel que sembla, això és un error (hi ha una aplicació? No l'he pogut trobar).

С haikuporter i repositori haikuports No té una sensació de "just funciona", però com a desenvolupador, hi ha algunes coses que m'agraden de treballar amb Haiku. En la seva major part, és similar al servei de compilació oberta, un conjunt d'eines per crear compilacions de Linux: extremadament potent, amb un enfocament sistemàtic, però excessiu per a la meva petita aplicació "hola món".

De nou, segons el Sr. waddlesplash:

De fet, HaikuPorter és bastant estricte per defecte (a més, hi ha un mode pelusa i un mode estricte per fer-lo encara més estricte!), Però només perquè crea paquets que funcionaran, en lloc de crear paquets. Per això es queixa de dependències no declarades, biblioteques no importades correctament, versions incorrectes, etc. L'objectiu és detectar tots els problemes, inclosos els futurs, abans que l'usuari se n'assabenti (és per això que no va ser possible instal·lar avrdude, perquè la dependència s'especificava realment a la recepta). Les biblioteques no són només paquets individuals o fins i tot versions SO específiques. HaikuPorter assegura que tot això s'observa en les pròpies receptes per evitar errors durant l'execució.

En principi, aquest nivell de rigor està justificat a l'hora de crear un sistema operatiu, però em sembla innecessari per a una aplicació "hello world". Vaig decidir provar una altra cosa.

Creació d'aplicacions en format hpkg mitjançant l'ordre "crear paquets".

Pot ser, això Les instruccions senzilles em funcionaran millor?

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

Inesperadament ràpid, inesperadament senzill, inesperadament efectiu. Exactament com m'agrada, increïble!

Instal·lació: què i on?

S'ha mogut el fitxer QtQuickApp.hpkg a ~/config/packagesutilitzant un gestor de fitxers, després del qual QtQuickApp va aparèixer màgicament ~/config/apps.
De nou, inesperadament ràpid, senzill i eficaç. Increïble, increïble!

Però... (on seríem sense ells!)

L'aplicació encara falta a la llista del menú d'aplicacions i a QuickLaunch. Crec que ja sé com arreglar-ho. Al gestor de fitxers movo QtQuickApp.hpkg de ~/config/packages a /system/packages.

No, encara falta. Pel que sembla, em vaig perdre alguna cosa (bé, i les instruccions).

Després d'haver mirat la pestanya "Contingut" a HaikuDepot per a altres aplicacions, vaig veure que hi ha fitxers com /data/mimedb/application/x-vnd... el que és encara més remarcable /data/deskbar/menu/Applications/….

Bé, què hi he de posar? Vinga...

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

Estic molt segur que aquest truc funcionarà, però les preguntes segueixen sent: per què és necessari, per a què serveix? Crec que això arruïna la impressió general que el sistema és tan sofisticat.

Tal com ha explicat el Sr. waddlesplash:

De vegades hi ha aplicacions que necessiten altres aplicacions però que no estan al menú. Per exemple, LegacyPackageInstaller a la vostra captura de pantalla, processant arxius .pkg en format BeOS. M'agradaria que els usuaris els instal·lin, però la seva presència al menú generarà confusió.

Per alguna raó em sembla que hi ha una solució més senzilla, per exemple Hidden=true en fitxers .desktop a Linux. Per què no convertir la informació "oculta" en un recurs i atribut del sistema de fitxers?

El que no és especialment subtil és el nom de (alguna) aplicació que mostra el menú, deskbar, rígidament lligat pel camí.

Sr. waddlesplash explica això:

"Barra d'escriptori" en aquest cas s'ha d'entendre com una mena de terme general (de la mateixa manera que "barra de tasques", que fa referència tant a l'aplicació de Windows com al concepte general). Bé, des d'això deskbar, no "Deskbar", això també es pot entendre d'una manera similar.

2 directoris "gairebé idèntics" amb aplicacions en ells

Per què hi ha 2 directoris amb aplicacions, i també per què el meu QtQuickApplication està en un, però no en l'altre? (Després de tot, aquest no és un sistema, sinó un segon usuari, cosa que seria comprensible per a mi personalment).
Estic molt confós i crec que això s'hauria d'unificar.

comentari del Sr. waddlesplash

El catàleg d'aplicacions conté aplicacions que no són necessàries al menú. Però la situació amb el menú realment s'ha de millorar, perquè sigui més personalitzable.

Aplicació, o no passarà 😉

Em vaig preguntar: és realment necessari allotjar aplicacions? /system/apps, si els usuaris els veuen allà, no és desitjable. Potser seria millor col·locar-los en un altre lloc on l'usuari no els trobarà? Igual que es fa a Mac OS X, on el contingut dels paquets .app, que no hauria de ser visible per a l'usuari /Applications, amagat a les profunditats de /System/Library/…“`.

Què passa amb les dependències?

Crec que val la pena especificar les dependències d'alguna manera, oi? Es pot considerar Qt una part obligatòria de la instal·lació de Haiku per defecte? No! Qt no està instal·lat per defecte. Pot un creador de paquets detectar automàticament dependències comprovant els fitxers ELF? Em van dir que HaikuPorter realment fa això, però package No. Això és perquè només és un "creador de paquets" que només crea fitxers per si mateix hpkg.

S'hauria de sofisticar Haiku afegint una política que un paquet no hauria de tenir dependències de paquets fora de Haiku? haikuports? (M'agradaria, perquè aquesta política faria les coses molt més fàcils: el sistema podria resoldre automàticament les dependències de tots els paquets descarregats des de qualsevol lloc, sense fer-ho amb fonts addicionals de paquets.)

Sr. waddlesplash explica:

No ens agradaria limitar tant la llibertat dels desenvolupadors, perquè és obvi que si CompanyX vol donar suport al seu propi conjunt de programari amb dependències (i, per tant, un repositori), ho farà de manera totalment lliure.

En aquest cas, val la pena recomanar que els paquets de tercers evitin dependències de qualsevol cosa que no s'inclogui als haikuports empaquetant completament tot el necessari amb l'aplicació. Però crec que aquest és un tema per a un futur article d'aquesta sèrie. [L'autor es dirigeix cap a AppImage? —aprox. traductor]

Afegeix una icona d'aplicació

Què passa si vull afegir una de les bones icones integrades als recursos de la meva aplicació acabada de crear? Resulta que aquest és un tema sorprenent, de manera que serà la base del proper article.

Com organitzar les compilacions contínues d'aplicacions?

Imagineu un projecte com Inkscape (sí, sóc conscient que encara no està disponible a Haiku, però és convenient mostrar-hi). Tenen un dipòsit de codi font https://gitlab.com/inkscape/inkscape.
Cada vegada que algú confirma els seus canvis al repositori, s'inicien canalitzacions de compilació, després de la qual cosa els canvis es proveen, es construeixen i l'aplicació s'empaqueta en diversos paquets, inclòs AppImage per a Linux (un paquet d'aplicacions autònom que es pot descarregar per a proves locals independentment). què es pot instal·lar o no al sistema [Ho sabia! —aprox. traductor]). El mateix passa amb cada sol·licitud de fusió de branques, de manera que podeu descarregar l'aplicació creada a partir del codi proposat a la sol·licitud de fusió abans de la fusió.

Combina les sol·licituds amb estats de compilació i la possibilitat de descarregar els binaris compilats si la compilació té èxit (marcat en verd)

La compilació s'executa en contenidors Docker. GitLab ofereix corredors gratuïts a Linux, i crec que podria ser possible incloure els vostres propis corredors (per cert, no veig com funcionaria això per a sistemes com Haiku, que sé que no tenen Docker o equivalent, però també per a FreeBSD no hi ha Docker, de manera que aquest problema no és exclusiu de Haiku).

Idealment, les aplicacions Haiku es poden crear dins d'un contenidor Docker per a Linux. En aquesta situació, el muntatge per a Haiku es pot introduir a les canonades existents. Hi ha compiladors creuats? O hauria d'emular tots els Haiku dins d'un contenidor Docker utilitzant alguna cosa com QEMU/KVM (suposant que funcionarà així dins de Docker)? Per cert, molts projectes utilitzen principis similars. Per exemple, Scribus fa això: ja està disponible per a Haiku. Un dia arribarà el dia que puc enviar tal Traieu sol·licituds a altres projectes per afegir suport Haiku.

Un dels desenvolupadors explica:

Per a altres projectes que vulguin crear paquets ells mateixos, s'admet el mètode normal CMake/CPack. Es poden donar suport a altres sistemes de compilació trucant directament al programa de compilació del paquet, que està bé si la gent hi està interessada. L'experiència demostra: fins ara no hi ha hagut gaire interès, així que haikuporter ens ha funcionat tan convenient, però, en definitiva, tots dos mètodes haurien de funcionar conjuntament. Hauríem d'introduir un conjunt d'eines per a programari de construcció creuada de Linux o qualsevol altre sistema operatiu de servidor (Haiku no està dissenyat per executar-se en servidors).

Faig una ovació de peu. Els usuaris habituals de Linux porten tota aquesta càrrega addicional i equipatge addicional (seguretat, control estricte, etc.) que és necessari per a un sistema operatiu de servidor, però no per a un de personal. Per tant, estic completament d'acord que poder crear aplicacions Haiku a Linux és el camí a seguir.

Conclusió

Portar aplicacions POSIX a Haiku és possible, però pot ser més car que una reconstrucció típica. Definitivament, m'he quedat amb això durant molt de temps si no fos per l'ajuda de la gent del canal #haiku de la xarxa irc.freenode.net. Però fins i tot ells no sempre van veure immediatament què passava.

Les aplicacions escrites en Qt són una senzilla excepció. He creat una senzilla aplicació de demostració sense cap problema.

Construir un paquet per a aplicacions senzilles també és bastant fàcil, però només per a les "alliberades tradicionalment", és a dir. tenir arxius de codi font versionats destinats al suport en haikuports. Per a una construcció contínua (creació per a cada commissió de canvis) amb GitHub, sembla que no tot és tan senzill. Aquí Haiku sembla més una distribució de Linux que el resultat en un Mac, on quan feu clic al botó "Crear" a XCode obteniu un paquet .app, llest per ser inserit en una imatge de disc .dmg, preparat per descarregar al meu lloc web.
La construcció contínua d'aplicacions basades en un sistema operatiu "servidor", per exemple, Linux, probablement serà possible si hi ha demanda dels desenvolupadors, però de moment el projecte Haiku té altres tasques més urgents.

Prova-ho tu mateix! Després de tot, el projecte Haiku proporciona imatges per arrencar des de DVD o USB, generades diari. Per instal·lar-lo, només cal que descarregueu la imatge i escriu-la en una unitat flash utilitzant Etcher

Té vostè alguna pregunta? Et convidem a la parla russa canal de telegrama.

Visió general de l'error: Com disparar-se al peu en C i C++. Col·lecció de receptes Haiku OS

D' l'autor traducció: aquest és el cinquè article de la sèrie sobre Haiku.

Llista d'articles: La primera El segon La tercera Quart

Font: www.habr.com

El meu cinquè dia amb Haiku: portem alguns programes