🥇O meu quinto día con Haiku: portemos algúns programas

TL, RD: Un novato viu Haiku por primeira vez, intentando portar algúns programas do mundo Linux.

O meu primeiro programa portado Haiku, empaquetado no seu formato hpkg

Recentemente Descubrín Haiku, un sistema operativo sorprendentemente bo para ordenadores.
Hoxe aprenderei a portar novos programas a este sistema operativo. O foco principal é unha descrición da primeira experiencia de cambio a Haiku desde o punto de vista dun desenvolvedor de Linux. Pido desculpas polos erros estúpidos que cometín no camiño, xa que non pasou nin unha semana desde que descarguei Haiku por primeira vez.

Quero acadar tres obxectivos:

Port unha aplicación CLI sinxela
Porta unha aplicación da GUI a Qt
Despois empaquetaos en formato hpkg (xa que aínda estou pensando en adaptar AppDir e AppImage para Haiku...)

Imos comezar. En seccións a documentación и desenvolvementoasí como wiki de HaikuPorts atopei a dirección correcta. Incluso hai un libro PDF en liña BeOS: Portar unha aplicación Unix.
467 páxinas - e isto é de 1997! Dá medo mirar dentro, pero espero que sexa o mellor. As palabras do programador son alentadoras: "levou moito tempo porque BeOS non cumpría con POSIX", pero Haiku "na súa maior parte" xa é así.

Portar unha aplicación CLI sinxela

O primeiro pensamento foi portar a aplicación avrdude, pero, como se viu, isto xa é feito Hai moito tempo.

Primeiro intento: nada que ver

O que non podo entender é que xa As aplicacións portáronse a Haiku durante máis de 10 anos - a pesar de que o propio sistema operativo aínda non é a versión 1.0.

Segundo intento: necesidade de reescribir

Entón vou usar ptouch-770, CLI para controlar a impresora Brother P-Touch 770 que utilizo para imprimir etiquetas.
Imprimo nel varias etiquetas, e quizais xa o vira no artigo anterior. Un pouco antes, escribín un pequeno programa de envoltorio de GUI en Python (xa que está en Gtk+, terá que reescribirse, e esta é unha boa razón para aprender).

Impresora de etiquetas Brother P-Touch 770. Funcionará con Haiku?

O xestor de paquetes Haiku sabe sobre bibliotecas e comandos, polo que se recibo unha mensaxe "non se pode atopar libintl" ao executar configure - Acabo de lanzar pkgman install devel:libintl e atoparase o paquete necesario. Así mesmo pkgman install cmd:rsync. Ben, etc.

Excepto cando isto non 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

Quizais udev estea demasiado baseado en Linux e, polo tanto, non existe para Haiku. O que significa que teño que editar o código fonte que estou tentando compilar.
Eh, non podes saltar por riba da túa cabeza, e non sei nin por onde comezar.

Terceiro intento

Sería bo ter tmate para Haiku, entón permitiríalles aos desenvolvedores de Haiku conectarse á miña sesión de terminal, por se algo falla. As instrucións son bastante sinxelas:

./autogen.sh
./configure
make
make install

Parece ben, entón por que non probalo en 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

Neste paso abro HaikuDepot e busco curses.
Atopouse algo que me deu unha pista para unha consulta máis 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

De novo fun a HaikuDepot e, por suposto, atopeino devel:msgpack_c_cpp_devel. Cales son estes nomes estraños?

/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

Neste paso, decateime de que levar un programa a Haiku require moito máis coñecemento do necesario para unha simple reconstrución.
Falei cos amigables desenvolvedores de Haiku, resulta que hai un erro en msgpack e despois duns minutos vexo un parche en HaikuPorts. Podo ver cos meus propios ollos como se corrixiu o paquete indo aquí (buildslave - máquinas virtuais).

Creando o msgpack corrixido en buildmaster

Entre momentos envio un parche a upstream para engadir soporte de Haiku a msgpack.

Cinco minutos despois, o msgpack actualizado xa está dispoñible 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.

Inesperadamente bo. Dixen iso?!

Volvo ao problema orixinal:

/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

Agora parece que msgpack non ten a culpa. Estou comentando IMAXLABEL в tty.c así:

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

Resultado:

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.

Pois aquí volvemos... Por certo:

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

Señor. waddlesplash indica onde cavar:

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

Explicáronme que hai algo máis en libnetwork ademais de libresolv en Haiku. Ao parecer, o código debe ser editado máis. Hai que pensar…

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

A eterna pregunta: que está pasando?

/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

O mesmo, só de perfil. Googled e atopou isto. Se engades -lssp "ás veces" axuda, intento:

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

Vaia! Xa comeza! Pero…

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

Tentarei depurar arquivo aquí:

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

"Identificación de porto incorrecta" xa é como unha tarxeta de visita haiku. Quizais alguén teña unha idea do que está mal e como solucionalo? Se é así, actualizarei o artigo. Ligazón a GitHub.

Portando a aplicación GUI a Qt.

Escollo unha aplicación QML sinxela.

/> 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 sinxelo. Menos dun minuto!

Aplicacións de empaquetado en hpkg usando haikuporter e haikuports.

Por que debo comezar? Non hai documentación sinxela, vou á canle #haiku en irc.freenode.net e escoito:

Equipo package - unha forma de baixo nivel de crear paquetes. Na súa maior parte, PackageInfo é suficiente para ela, como se describe na sección "Convertilo nun paquete .hpkg adecuado"
Necesito facer algo tal
Pode usar hpkg-creador (me falla, informe de erros)

Non está claro que facer. Supoño que necesito unha guía para principiantes de estilo Hello World, o ideal é un vídeo. Sería bo ter tamén unha cómoda introdución a HaikuPorter, como se fai en GNU hello.

Estou lendo o seguinte:

haikuporter é unha ferramenta para crear proxectos de paquete común para Haiku. Usa o repositorio HaikuPorts como base para todos os paquetes. As receitas de haikuporter úsanse para crear paquetes.

Ademais, descubro que:

Non é necesario gardar receitas no almacenamento de HaikuPorts. Podes facer outro repositorio, poñer as receitas nel e, a continuación, apuntar a haikuporter.

Xusto o que necesito, se non busco un xeito de lanzar publicamente o paquete. Pero este é un tema para outra publicación.

Instalación de 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

Escribindo unha receita

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
}

Montaxe da receita

Gardo o ficheiro baixo o nome QtQuickApp-1.0.recipe, despois do cal lanzo aikuporter -S ./QuickApp-1.0.recipe. Compróbanse as dependencias de todos os paquetes do repositorio haikuports, que leva algún tempo. Vou tomar un café.

Por que debería facerse esta comprobación na miña máquina local e non centralmente no servidor unha vez por todos?

Segundo o sr. waddlesplash:

Con tal que podes reescribir calquera ficheiro do repositorio 😉 Podes optimizalo un pouco, calculando a información necesaria cando sexa necesario, porque os últimos cambios realizados son bastante raros.

~/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 non existe un ficheiro de receita normal que conteña o código fonte da túa aplicación. Debes gardalo nun repositorio no formato HaikuPorts.

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

Este feito fai que a montaxe sexa máis engorrosa. Non me gusta especialmente, pero creo que é necesario para que eventualmente todo o software de código aberto apareza en HaikuPorts.

Recibo o seguinte:

~/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 pasa? Despois de ler irc fago:

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

Xurdiu unha pregunta interesante. Se engado unha suma de verificación á receita, coincidirá co último commit de git para a integración continua? (O desenvolvedor confirma: "Non funcionará. As receitas están deseñadas para ser relativamente estables.")

Para divertirse, engade á receita:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Aínda non satisfeito:

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

Que está facendo? Despois de todo, este é un repositorio git, o código xa está alí directamente, non hai nada que desempaquetar. Desde o meu punto de vista, a ferramenta debería ser o suficientemente intelixente como para non buscar un descomprimidor se está por riba do URL de GitHub.

Quizais uri git:// funcione

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

Agora quéixase así:

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

Hmm, por que é todo tan complicado, por que non podes "só traballar"? Despois de todo, non é tan raro construír algo desde GitHub. Xa se trate de ferramentas que funcionan de inmediato, sen necesidade de configuración, ou como eu lle chamo "alfada".

Quizais funcione así:

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

Non. Aínda recibo este erro estraño e fago, como se describe aquí

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

Estou avanzando un pouco máis, pero por que me grita (GitHub non é seguro!) e aínda intenta desempaquetar algo.

Conforme Señor. waddlesplash:

Pois si, o motivo foi o desexo de comprobar a integridade dos datos recibidos para a súa montaxe. Unha das opcións é verificar a suma de comprobación do arquivo, pero pode, por suposto, hashar ficheiros individuais, que non se implementarán, porque leva moito máis tempo. A consecuencia disto é a "inseguridade" de git e outros VCS. Probablemente, este será sempre o caso, xa que crear un arquivo en GitHub é bastante sinxelo e moitas veces máis rápido. Pois ben, no futuro, quizais a mensaxe de erro non sexa tan rechamante... (xa non fusionamos este tipo de receitas en 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

Por un vello costume, vou preguntarlle a boa xente na canle #haiku da rede irc.freenode.net. E onde estaría eu sen eles? Despois da suxestión, decateime de que debería usar:

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

Está ben, quedou claro o que fai: descarga un arquivo co código fonte dunha determinada revisión. É estúpido, dende o meu punto de vista, e non é exactamente o que quería, é dicir, descargar a última revisión da rama mestra.

Un dos desenvolvedores explicouno deste xeito:

Temos o noso propio CI, polo que todo o que se coloque no repositorio de haikuports empaquetarase para todos os usuarios, e non queremos arriscarnos a recoller e entregar "todo a versión máis recente".

Entendido! En calquera caso, isto é o que pasou:

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

Repite isto ata o infinito. Ao parecer, isto é un erro (hai unha aplicación? Non puiden atopala).

С haikuporter e repositorio haikuports Non ten unha sensación de "só funciona", pero como programador, hai algunhas cousas que me gustan de traballar con Haiku. Na súa maior parte, é semellante ao Open Build Service, un conxunto de ferramentas para construír compilacións de Linux: extremadamente potente, cun enfoque sistemático, pero excesivo para a miña pequena aplicación "hola mundo".

De novo, segundo o sr. waddlesplash:

De feito, HaikuPorter é bastante estrito por defecto (ademais hai un modo lint e un modo estrito para facelo aínda máis estrito!), pero só porque crea paquetes que funcionarán, en lugar de só crear paquetes. Por iso denuncia dependencias non declaradas, bibliotecas non importadas correctamente, versións incorrectas, etc. O obxectivo é detectar calquera e todos os problemas, incluídos os futuros, antes de que o usuario se entere (por iso non foi posible instalar avrdude, porque a dependencia estaba realmente especificada na receita). As bibliotecas non son só paquetes individuais ou incluso versións específicas de SO. HaikuPorter garante que todo isto se observa nas propias receitas para evitar erros durante a execución.

En principio, este nivel de rigor xustifícase á hora de crear un sistema operativo, pero paréceme innecesario para unha aplicación "hello world". Decidín probar outra cousa.

Creación de aplicacións en formato hpkg usando o comando "crear paquete".

Pode ser, эта As instrucións sinxelas funcionarán mellor para min?

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

Inesperadamente rápido, inesperadamente sinxelo, inesperadamente efectivo. Exactamente como me gusta, incrible!

Instalación - que e onde?

Moveuse o ficheiro QtQuickApp.hpkg a ~/config/packagesusando un xestor de ficheiros, despois de que QtQuickApp apareceu por arte de maxia ~/config/apps.
De novo, inesperadamente rápido, sinxelo e eficaz. Incrible, incrible!

Pero... (onde estaríamos sen eles!)

A aplicación aínda falta na lista do menú de aplicacións e no QuickLaunch. Creo que xa sei como solucionalo. No xestor de ficheiros movo QtQuickApp.hpkg de ~/config/packages a /system/packages.

Non, aínda falta. Ao parecer, eu (ben, e as instrucións) perdín algo.

Despois de mirar a pestana "Contidos" en HaikuDepot para algunhas outras aplicacións, vin que hai ficheiros como /data/mimedb/application/x-vnd... o que é aínda máis notable /data/deskbar/menu/Applications/….

Ben, que debo poñer alí? Veña...

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

Estou bastante seguro de que este truco funcionará, pero quedan as preguntas: por que é necesario, para que serve? Creo que isto arruina a impresión xeral de que o sistema é tan sofisticado.

Segundo explica o Sr. waddlesplash:

Ás veces hai aplicacións que necesitan outras aplicacións pero que non están no menú. Por exemplo, LegacyPackageInstaller na súa captura de pantalla, procesando arquivos .pkg en formato BeOS. Gustaríame que os usuarios as instalen, pero a súa presenza no menú provocará confusión.

Por algún motivo paréceme que hai unha solución máis sinxela, por exemplo Hidden=true en arquivos .desktop en Linux. Por que non facer que a información "oculta" sexa un recurso e un atributo do sistema de ficheiros?

O que non é especialmente sutil é o nome de (algunha) aplicación que mostra o menú, deskbar, ríxidamente atados ao longo do camiño.

Señor. waddlesplash explica isto:

"Deskbar" neste caso debe entenderse como unha especie de termo xeral (do mesmo xeito que "barra de tarefas", que se refire tanto á aplicación de Windows como ao concepto xeral). Pois dende isto deskbar, non "Deskbar", isto tamén se pode entender dun xeito similar.

2 directorios "case idénticos" con aplicacións neles

Por que hai 2 directorios con aplicacións, e tamén por que está o meu QtQuickApplication nun, pero non no outro? (Despois de todo, este non é un sistema, senón un segundo usuario, que sería comprensible para min persoalmente).
Estou moi confuso e creo que isto debería unificarse.

comentario do sr. waddlesplash

O catálogo de aplicacións contén aplicacións que non son necesarias no menú. Pero realmente hai que mellorar a situación co menú, para facelo máis personalizable.

Solicitude, ou non sucederá 😉

Pregunteime: é realmente necesario aloxar aplicacións? /system/apps, se os usuarios os ven alí, non é desexable. Quizais sería mellor colocalos noutro lugar onde o usuario non os atope? Do mesmo xeito que se fai en Mac VOS X, onde o contido dos paquetes .app, que non debería ser visible para o usuario en /Applications, agochado nas profundidades de /System/Library/…“`.

Que pasa coas dependencias?

Creo que paga a pena especificar as dependencias dalgún xeito, non? Pódese considerar Qt unha parte obrigatoria da instalación de Haiku por defecto? Non! Qt non está instalado por defecto. Pode un creador de paquetes detectar automaticamente dependencias comprobando os ficheiros ELF? Dixéronme que HaikuPorter realmente fai isto, pero package Non. Isto é porque é só un "construtor de paquetes" que só crea ficheiros por si mesmo hpkg.

Haiku debería ser máis sofisticado engadindo unha política de que un paquete non debería ter dependencias de paquetes fóra de Haiku? haikuports? (Gustaríame, porque unha política deste tipo faría as cousas moito máis fáciles: o sistema podería resolver automaticamente as dependencias de cada paquete descargado desde calquera lugar, sen xogar con fontes adicionais de paquetes).

Señor. waddlesplash explica:

Non nos gustaría limitar tanto a liberdade dos desenvolvedores, porque é obvio que se CompanyX quere soportar o seu propio conxunto de software con dependencias (e polo tanto un repositorio), farao de forma totalmente libre.

Nese caso, pode valer a pena recomendar que os paquetes de terceiros eviten as dependencias de calquera cousa que non se inclúa nos haikuports embalando completamente todo o necesario coa aplicación. Pero creo que este é un tema para un futuro artigo desta serie. [Está o autor en dirección a AppImage? - aprox. tradutor]

Engadir unha icona de aplicación

E se quero engadir unha das boas iconas integradas aos recursos da miña aplicación recentemente creada? Resulta que este é un tema incrible, polo que será a base para o próximo artigo.

Como organizar as compilacións continuas de aplicacións?

Imaxina un proxecto como Inkscape (si, sei que aínda non está dispoñible en Haiku, pero é conveniente mostrar nel). Teñen un repositorio de código fonte https://gitlab.com/inkscape/inkscape.
Cada vez que alguén compromete os seus cambios no repositorio, lánzanse canalizacións de compilación, despois do cal os cambios son probados, construídos automaticamente e a aplicación empaquetada en varios paquetes, incluíndo AppImage para Linux (un paquete de aplicacións independente que se pode descargar para probas locais independentemente de o que pode instalarse ou non no sistema [Sabíao! - aprox. tradutor]). O mesmo ocorre con todas as solicitudes de fusión de ramas, polo que podes descargar a aplicación construída a partir do código proposto na solicitude de fusión antes de fusionar.

Combinar solicitudes cos estados de compilación e a posibilidade de descargar os binarios compilados se a compilación é exitosa (marcado en verde)

A compilación execútase en contedores Docker. GitLab ofrece corredores gratuítos en Linux, e creo que pode ser posible incluír os teus propios corredores (por certo, non vexo como funcionaría isto para sistemas como Haiku, que sei que non teñen Docker ou equivalente, pero tamén para FreeBSD non hai Docker, polo que este problema non é exclusivo de Haiku).

Idealmente, as aplicacións Haiku pódense construír dentro dun contedor Docker para Linux. Nesta situación, a montaxe para Haiku pódese introducir nas conducións existentes. Hai compiladores cruzados? Ou debería emular todo o Haiku dentro dun contedor Docker usando algo como QEMU/KVM (asumindo que funcionará así dentro de Docker)? Por certo, moitos proxectos usan principios similares. Por exemplo, Scribus fai isto: xa está dispoñible para Haiku. Un día chegará o día no que poida enviar tal Tira solicitudes a outros proxectos para engadir soporte para Haiku.

Un dos desenvolvedores explica:

Para outros proxectos que desexen crear paquetes por si mesmos, é compatible o método normal CMake/CPack. Outros sistemas de compilación poden ser compatibles chamando directamente ao programa de compilación do paquete, o que está ben se a xente está interesada nel. A experiencia demostra: ata agora non houbo moito interese, polo que haikuporter funcionou como conveniente para nós, pero, en definitiva, ambos os métodos deberían funcionar xuntos. Deberíamos introducir un conxunto de ferramentas para a creación cruzada de software desde Linux ou calquera outro sistema operativo de servidor (Haiku non está deseñado para executarse en servidores).

Dou unha ovación de pé. Os usuarios habituais de Linux levan toda esta carga adicional e equipaxe adicional (seguridade, control estrito, etc.) que é necesario para un sistema operativo de servidor, pero non para un persoal. Entón estou totalmente de acordo en que poder construír aplicacións Haiku en Linux é o camiño a seguir.

Conclusión

Portar aplicacións POSIX a Haiku é posible, pero pode ser máis caro que unha reconstrución típica. Definitivamente quedaría atascado con isto durante moito tempo se non fose pola axuda da xente da canle #haiku na rede irc.freenode.net. Pero mesmo eles non sempre viron inmediatamente o que estaba mal.

As aplicacións escritas en Qt son unha excepción sinxela. Elaborei unha sinxela aplicación de demostración sen ningún problema.

Construír un paquete para aplicacións sinxelas tamén é bastante doado, pero só para as "tradicionais", é dicir. ter arquivos de código fonte versionados destinados ao soporte en haikuports. Para unha compilación continua (construír para cada commit de cambios) con GitHub, todo parece non ser tan sinxelo. Aquí Haiku parece máis unha distribución de Linux que o resultado nunha Mac, onde cando fai clic no botón "Construír" en XCode obtén un paquete .app, listo para ser inserido nunha imaxe de disco .dmg, preparado para descargar no meu sitio web.
A construción continua de aplicacións baseadas nun sistema operativo "servidor", por exemplo, Linux, probablemente será posible se hai demanda dos desenvolvedores, pero polo momento o proxecto Haiku ten outras tarefas máis urxentes.

Probao vostede mesmo! Despois de todo, o proxecto Haiku ofrece imaxes para o arranque desde DVD ou USB, xeradas diario. Para instalala, só tes que descargar a imaxe e escribira nunha unidade flash usando Etcher

Tes algunha dúbida? Convidámoste ao rusofalante canle de telegrama.

Visión xeral do erro: Como dispararse no pé en C e C++. Colección de receitas Haiku OS

De autor tradución: este é o quinto artigo da serie sobre o haiku.

Lista de artigos: Primeira O segundo Terceiro Cuarto

Fonte: www.habr.com

O meu quinto día con Haiku: portemos algúns programas