TL;DR: Un novato vio Haiku por primera vez, intenta portar algunos programas del mundo Linux.
Mi primer programa portado para Haiku, empaquetado en su formato hpkg
descubrí Haiku, un sistema operativo para PC sorprendentemente bueno.
Hoy voy a aprender a portar nuevos programas a este sistema operativo. El enfoque principal es la descripción de la primera experiencia de transición a Haiku desde la perspectiva de un desarrollador para Linux. Pido disculpas por los errores tontos cometidos en el proceso, ya que desde que cargué Haiku por primera vez no ha pasado ni una semana.
Quiero alcanzar tres objetivos:
- Portar una simple aplicación CLI
- Portar una aplicación con GUI en Qt
- Luego empaquetarlas en formato hpkg (ya que aún estoy considerando la adaptación de AppDir y AppImage para Haiku...)
Vamos a empezar. En las secciones y , así como en de HaikuPorts encontré la dirección correcta. Incluso hay un libro en línea PDF .
467 páginas — ¡y eso es desde 1997! Es intimidante mirar dentro, pero espero lo mejor. Las palabras del desarrollador son alentadoras: "toma tiempo, porque BeOS no era compatible con POSIX", pero Haiku "en su mayor parte" ya lo es.
Portando una simple aplicación CLI
El primer pensamiento fue portar la aplicación , pero, como resultó, eso ya hace mucho tiempo.
Primer intento: no hay nada que ver
Lo que no puedo entender es que ya han pasado más de 10 años desde que las aplicaciones se están portando a Haiku Segundo intento: necesito reescribir
Así que, usaré
ptouch-770 Imprimo varias etiquetas en ella, y quizás ya la hayas visto en el artículo anterior. Hace poco escribí un pequeño programa wrapper con GUI en Python (como está en Gtk+ — tendré que reescribirlo, y es una buena oportunidad para aprender).
Impresora de etiquetas Brother P-Touch 770. ¿Funcionará bajo Haiku?
El gestor de paquetes de Haiku conoce las bibliotecas y los comandos, así que si recibo el mensaje «no se puede encontrar libintl» al iniciar
configure — simplemente ejecuto pkgman install devel:libintl y el paquete necesario será encontrado. De manera similar pkgman install cmd:rsync . Bueno, y así sucesivamente.Excepto en casos donde esto no funcione:
Quizás udev sea demasiado linux, por lo que no existe para Haiku. Lo que significa que necesitaré modificar el código fuente que intento compilar.
/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Возможно udev слишком линуксячий, поэтому не существует для Haiku. Что означает необходимость правки исходного кода, который я пытаюсь скомпилировать.
Vaya, no se puede saltar más alto de lo que uno puede, y ni siquiera sé por dónde empezar.
El tercer intento
Sería bueno tener tmate para Haiku, entonces permitiría que los desarrolladores de Haiku se conectaran a mi sesión de terminal, por si acaso algo sale mal. Las instrucciones son bastante simples:
./autogen.sh
./configure
make
make installSe ve bien, así que, ¿por qué no intentar esto 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 foundEn este paso, abro HaikuDepot y busco curses.
Encontré algo que me dio una pista para una solicitud más precisa:
/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 foundVolví a HaikuDepot, y por supuesto encontré devel:msgpack_c_cpp_devel. ¿Qué nombres tan extrañ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 1En este paso me di cuenta de que portar el programa a Haiku requiere significativamente más conocimientos de los necesarios para una simple recompilación.
Hablé con desarrolladores amigables de Haiku, resultó que hay un error en msgpack, y en unos minutos veo un patch en HaikuPorts. Estoy viendo cómo se compila el paquete corregido (buildslave — máquinas virtuales).
Construyendo el msgpack corregido en buildmaster
Mientras tanto, envío el patch a upstream .
Cinco minutos después, el msgpack actualizado ya 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.Sorprendentemente bien. ¿Lo dije yo?!
Regreso a la tarea 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 1Ahora, parece que msgpack no es el culpable. Comento IMAXLABEL en tty.c así que:
tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|/*IMAXBEL|*/ISTRIP);Resultado:
osdep-unknown.c: En la función 'osdep_get_cwd':
osdep-unknown.c:32:19: advertencia: parámetro no utilizado 'fd' [-Wunused-parameter]
osdep_get_cwd(int fd)
~~~~^~
make: *** No hay regla para hacer el objetivo 'compat/forkpty-unknown.c', necesario por 'compat/forkpty-unknown.o'. Detener.Bueno, aquí vamos otra vez… Por cierto:
/Haiku/home/tmate> ./configure | grep -i OPENAT
checking for openat... nosugiere hacia dónde investigar:
/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í subí .
Me explicaron que hay algo más en libresolv en Haiku en libnetwork. Al parecer, hay que seguir trabajando en el código. Necesito pensar...
find . -type f -exec sed -i -e 's|lresolv|lnetwork|g' {} ;La eterna pregunta: ¿qué 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 foundLo mismo, pero en perfil. Googleé y . Si añades -lssp a veces ayuda, lo estoy probando:
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp"
(...)/Haiku/home/tmate> make
(...)/Haiku/home/tmate> ./tmate¡Vaya! ¡Está funcionando! Pero...
[tmate] fallo de búsqueda ssh.tmate.io. Reintentando en 2 segundos (fallo irrecuperable en la resolución de nombres)Intentaré depurarlo, :
/Haiku/home/tmate> strace -f ./tmate >log 2>&1"Bad port ID" — esto es como una tarjeta de presentación . Quizás alguien sepa qué está mal y cómo solucionarlo. Si hay novedades, actualizaré el artículo. Enlace a .
El porte de una aplicación GUI a Qt.
Elijo una aplicación simple en QML.
/> cd /Haiku/home//Haiku/home> git clone https://github.com/probonopd/QtQuickApp
/Haiku/home/QtQuickApp> qmake .
/Haiku/home/QtQuickApp> make
/Haiku/home/QtQuickApp> ./QtQuickApp # Works!Realmente simple. ¡Menos de un minuto!
Empaquetando aplicaciones en hpkg usando haikuporter y haikuports.
¿Por dónde empezar? No hay documentación sencilla, voy al canal #haiku en irc.freenode.net y escucho:
- Comando
package— un método de bajo nivel para crear paquetes. En su mayor parte, es suficiente con PackageInfo, tal como se describe en la sección «Convirtiéndolo en un paquete .hpkg adecuado» - Necesito hacer algo
- Puedes usar (se me cierra, )
No entiendo qué hacer. Creo que necesito un manual para principiantes al estilo de «¡Hola, Mundo!», idealmente, un video. También sería bueno tener una introducción amigable a HaikuPorter, como se hace en GNU hello.
Leo lo siguiente:
haikuporteres una herramienta para crear proyectos de paquetes generales para Haiku. Utiliza el repositorio HaikuPorts como base para todos los paquetes. Se utilizan recetas de haikuporter para crear paquetes.
Adicionalmente, descubro que:
No es necesario mantener las recetas en el almacenamiento de HaikuPorts. Se puede crear otro repositorio, colocar las recetas en él y luego indicarle a haikuporter que lo use.
Es justo lo que necesito, si no busco una manera de publicar el paquete. Pero ese es un tema para otro post.
Instalación de haikuporter y 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/ # hacerlo ejecutable desde cualquier lugar
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.confEscribir una receta
SUMMARY="Aplicación demo de QtQuick"
DESCRIPTION="QtQuickApp es una aplicación demo de QtQuick para probar la portabilidad y empaquetado de Haiku"
HOMEPAGE="https://github.com/probonopd/QtQuickApp"
COPYRIGHT="Ninguno"
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
}Construcción de la receta
Guardando el archivo con el nombre QtQuickApp-1.0.recipe, después ejecuto haikuporter -S ./QuickApp-1.0.recipe. Se comprueban las dependencias para todos los paquetes en el repositorio , lo que toma un tiempo. Iré a tomar un café.
¿Y por qué esta verificación debería hacerse en mi máquina local en lugar de de manera centralizada en el servidor una vez para todos?
Según el sr. waddlesplash:
Con la ventaja de que se puede reescribir cualquier archivo en el repositorio 😉 Se podría optimizar un poco esto, calculando la información necesaria cuando sea necesario, ya que los últimos cambios realizados son bastante raros.
~/QtQuickApp> haikuporter QtQuickApp-1.0.recipe
Verificando si alguna información de dependencia necesita ser actualizada ...
Buscando información de dependencia obsoleta ...
Error: QtQuickApp no encontrado en el repositorioParece que no existe un archivo de receta estándar que contenga el código fuente de tu aplicación. Debes mantenerlo en el repositorio en formato HaikuPorts.
~\/QtQuickApp> mv QtQuickApp-1.0.recipe ..\/haikuports\/app-misc\/QtQuickApp\/\n~\/QtQuickApp> ..\/haikuport\n~\/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipeEste hecho hace que la construcción sea más engorrosa. No me gusta especialmente, pero creo que es necesario para que, al final, todo el software de código abierto esté disponible en HaikuPorts.
Recibo lo siguiente:
~\/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe\nComprobando si es necesario actualizar alguna información de dependencias ...\n actualizando la información de dependencias de QtQuickApp-1.0\nBuscando información de dependencias obsoletas ...\nError: QtQuickApp-1.0.recipe no encontrado en el árbol.¿Qué está mal? Después de leer IRC, hago:
~\/QtQuickApp> haikuporter -S QtQuickApp\nComprobando si es necesario actualizar alguna información de dependencias ...\n actualizando la información de dependencias de QtQuickApp-1.0\nBuscando información de dependencias obsoletas ...\n----------------------------------------------------------------------\napp-misc::QtQuickApp-1.0\n \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe\n----------------------------------------------------------------------Descargando: https:\/\/github.com\/probonopd\/QtQuickApp.git ...\n--2019-07-14 16:12:44-- https:\/\/github.com\/probonopd\/QtQuickApp.git\nResolviendo github.com... 140.82.118.3\nConectando a github.com|140.82.118.3|:443... conectado.\nSolicitud HTTP enviada, esperando respuesta... 301 Moved Permanently\nUbicación: https:\/\/github.com\/probonopd\/QtQuickApp [siguiendo]\n--2019-07-14 16:12:45-- https:\/\/github.com\/probonopd\/QtQuickApp\nReutilizando conexión existente a github.com:443.\nSolicitud HTTP enviada, esperando respuesta... 200 OK\nLongitud: no especificada [text\/html]\nGuardando en: ‘\/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git’\n 0K . 1.34M=0.06s\n2019-07-14 16:12:45 (1.34 MB\/s) - ‘\/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git’ guardado [90094]\nValidando el checksum de QtQuickApp.git\nAdvertencia: ----- CHECKSUM TEMPLATE -----\nAdvertencia: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"\nAdvertencia: -----------------------------\nError: No se encontró ningún checksum en la receta!Surge una pregunta interesante. Si agrego un checksum a la receta, ¿corresponderá este al último commit en git para la integración continua? (El desarrollador confirma: «No funcionará. Las recetas están diseñadas para ser relativamente estables»).
Por diversión, añaden a la receta:
CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"Todavía no es satisfactorio:
~\/QtQuickApp> haikuporter -S QtQuickApp\nComprobando si es necesario actualizar alguna información de dependencias ...\n actualizando la información de dependencias de QtQuickApp-1.0\nBuscando información de dependencias obsoletas ...\n----------------------------------------------------------------------\napp-misc::QtQuickApp-1.0\n \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe\n----------------------------------------------------------------------\nSaltando descarga de fuente para QtQuickApp.git\nValidando el checksum de QtQuickApp.git\nDesempaquetando la fuente de QtQuickApp.git\nError: Tipo de archivo de archivo no reconocido en el archivo \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git¿Por qué es así? Es un repositorio git, el código ya está allí directamente, no hay nada que descomprimir. Desde mi punto de vista, la herramienta debería ser lo suficientemente inteligente como para no buscar un descompresor si se encuentra con una URL de GitHub.
Quizás funcione uri git://
SOURCE_URI="git://github.com/probonopd/QtQuickApp.git"Ahora se queja así:
Descargando: git://github.com/probonopd/QtQuickApp.git ...
Error: ¡La descarga desde fuentes no seguras está deshabilitada en haikuports.conf!Hmm, ¿y por qué es todo tan complicado? ¿Por qué no puede «simplemente funcionar»? Después de todo, no es tan raro compilar algo desde GitHub. Es mucho mejor las herramientas que funcionan de inmediato, sin necesidad de configuración, o como yo lo llamo «molestias».
Tal vez funcione así:
SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"No. Todavía obtengo ese error extraño y hago,
sed -i -e 's|#ALLOW_UNSAFE_SOURCES|ALLOW_UNSAFE_SOURCES|g' /boot/home/config/settings/haikuports.confAvanzo un poco más, pero ¿por qué me grita (¡GitHub no es seguro!) y todavía intenta descomprimir algo?
Según :
Sí, la razón fue el deseo de verificar la integridad de los datos obtenidos para la compilación. Una de las opciones es verificar la suma de verificación del archivo, pero también se pueden hashizar archivos individuales, lo que no se implementará ya que toma mucho más tiempo. Como resultado, esto es lo que significa la «inseguridad» de git y otros VCS. Es probable que esto siempre sea así, ya que crear un archivo en GitHub es bastante fácil y a menudo más rápido. Además, en el futuro, posiblemente el mensaje de error no será tan alarmante… (ya no fusionamos esas recetas en HaikuPorts).
~/QtQuickApp> haikuporter -S QtQuickApp
Comprobando si es necesario actualizar alguna información de dependencia ...
Buscando información de dependencia obsoleta ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
/boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Descargando: git+https://github.com/probonopd/QtQuickApp.git ...
Advertencia: LAS FUENTES NO SEGURAS SON MALAS Y NO DEBERÍAN USARSE EN PRODUCCIÓN
Advertencia: ¡MUEVASE A UNA DESCARGA DE ARCHIVO ESTÁTICO CON SUMA DE VERIFICACIÓN LO ANTES POSIBLE!
Clonando en el repositorio vacío '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
Descomponiendo la fuente de QtQuickApp.git
tar: /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0: No se puede abrir: No existe el archivo o directorio
tar: El error no es recuperable: saliendo ahora
El comando 'git archive HEAD | tar -x -C "/boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0"' devolvió un estado de salida distinto de cero 2Por costumbre, voy a preguntar a las buenas personas en el canal #haiku en la red irc.freenode.net. ¿Y a dónde iría sin ellos? Después de un consejo, entendí que debía usar:
srcGitRev="d0769f53639eaffdcd070bddfb7113c04f2a0de8"
SOURCE_URI="https://github.com/probonopd/QtQuickApp/archive/$srcGitRev.tar.gz"
SOURCE_DIR="QtQuickApp-$srcGitRev"
CHECKSUM_SHA256="db8ab861cfec0ca201e9c7b6c0c9e5e828cb4e9e69d98e3714ce0369ba9d9522"Está claro lo que hace: descarga un archivo comprimido con el código fuente de una revisión específica. Me parece una tontería y no es exactamente lo que quería, a saber: descargar la última revisión de la rama principal.
Uno de los desarrolladores lo explicó así:
Tenemos nuestro propio CI, así que todo lo que se coloca en el repositorio haikuports se empaquetará para todos los usuarios, y no queremos correr el riesgo de compilar y distribuir "todas las últimas versiones de upstream".
¡Entendido! En cualquier caso, resultó así:
esperando que se active el paquete de construcción QtQuickApp-1.0-1
esperando que se active el paquete de construcción QtQuickApp-1.0-1
esperando que se active el paquete de construcción QtQuickApp-1.0-1
esperando que se active el paquete de construcción QtQuickApp-1.0-1
esperando que se active el paquete de construcción QtQuickApp-1.0-1
(...)Repite esto indefinidamente. Supongo que es un error (¿hay un ticket? no lo encontré).
Con haikuporter y el repositorio no se siente como un nivel de "simplemente funciona", pero como desarrollador, hay algunas cosas sobre trabajar con Haiku que me gustan. En su mayoría, se parece a Open Build Service: un conjunto de herramientas para construir distribuciones de Linux: extremadamente potente, con un enfoque sistémico, pero excesivo para mi pequeña aplicación de tipo "hello world".
De nuevo, según el sr. waddlesplash:
De hecho, HaikuPorter es bastante estricto por defecto (además hay modo lint y modo estricto, que lo hacen aún más estricto), pero solo porque crea paquetes que funcionarán, y no simplemente paquetes. Por eso se queja de dependencias no declaradas, bibliotecas no importadas adecuadamente, versiones incorrectas, etc. El objetivo es atrapar todos los problemas, incluidos los futuros, antes de que el usuario se entere (por eso no pude instalar avrdude, ya que en la receta se había indicado realmente una dependencia). Las bibliotecas no son solo paquetes separados y ni siquiera versiones definidas de SO. HaikuPorter se asegura del cumplimiento de todo esto en las propias recetas para evitar errores en tiempo de ejecución.
En principio, este nivel de rigor es justificable al crear un sistema operativo, pero me parece excesivo para una aplicación "hello world". Decidí probar algo diferente.
Construcción de aplicaciones en formato hpkg, usando el comando "package create"
Quizás, sencilla instrucción me convenga mejor?
mkdir -p apps/
cp QtQuickApp apps/cat > .PackageInfo <<EOF
name QtQuickApp
version 1.0-1
architecture x86_64
summary "Aplicación de demostración de QtQuick"
description "QtQuickApp es una aplicación de demostración de QtQuick para probar la portabilidad y empaquetado de 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# Ver a continuación si también deseas que la aplicación
# aparezca en el menúSorprendentemente rápido, sorprendentemente simple, sorprendentemente efectivo. Exactamente como me gusta, ¡increíble!
Instalación — ¿qué y dónde?
Moví el archivo QtQuickApp.hpkg a ~/config/packages, utilizando el administrador de archivos, después de lo cual QtQuickApp apareció mágicamente en ~/config/apps.
Nuevamente sorprendentemente rápido, simple y efectivo. ¡Increíble, increíble!
Pero… (¿cómo no tenerlos!)
La aplicación todavía no aparece en la lista de aplicaciones y en QuickLaunch. Creo que ya sé cómo solucionarlo. En el administrador de archivos muevo QtQuickApp.hpkg de ~/config/packages a /system/packages.
No, todavía no está. Al parecer, yo (bueno, y las instrucciones) me perdí algo.
Al revisar la pestaña 'Contents' en HaikuDepot para algunas otras aplicaciones, vi que hay archivos como /data/mimedb/application/x-vnd... lo que es aún más notable, /data/deskbar/menu/Applications/….
¿Y qué debería colocar allí? Déjame pensar...
mkdir -p data/deskbar/menu/Applications/
( cd data/deskbar/menu/Applications ; ln -s ..//..//..//..//apps/QtQuickApp . )
package add QtQuickApp.hpkg apps dataEstoy bastante seguro de que este truco funcionará, pero tengo preguntas: ¿por qué es necesario, para qué se necesita? Creo que esto arruina la impresión general de que el sistema es tan sofisticado.
Como explicó mr. waddlesplash:
A veces hay aplicaciones que son necesarias para otras aplicaciones, pero no deben estar en el menú. Por ejemplo, LegacyPackageInstaller en tu captura de pantalla, que maneja archivos .pkg en formato BeOS. Se quiere que los usuarios lo instalen, pero su presencia en el menú causará confusión.
Tengo la impresión de que hay una solución más simple, como Hidden=true en los archivos .desktop en Linux. ¿Por qué no hacer que la información "oculta" sea un recurso y un atributo del sistema de archivos?
Lo que no es especialmente sofisticado es el nombre (de alguna) aplicación que muestra el menú, deskbar, que está fuertemente vinculado en la ruta.
mr. waddlesplash comenta sobre esto:
"Deskbar" en este caso debe entenderse como un término general (más o menos como "taskbar", que se refiere tanto a una aplicación de Windows como a un concepto general). Y dado que esto
deskbar, y no "Deskbar", también se puede entender de manera similar.
2 catálogos "casi idénticos" de aplicaciones en ellos
¿Por qué hay 2 catálogos de aplicaciones y por qué en uno está mi QtQuickApplication y en el otro no? (Después de todo, no es un sistema, sino un segundo usuario, lo que personalmente sería comprensible para mí).
Realmente estoy confundido y creo que debería unificarse esto.
comentario de mr. waddlesplash
En el catálogo de Apps hay aplicaciones que no son necesarias en el menú. Pero la situación con el menú realmente necesita mejorar, haciéndolo más personalizable.
Solicitud, o esto no sucederá 😉
Me pregunto: ¿es realmente necesario colocar aplicaciones en /system/apps, si los usuarios no deberían verlas allí? ¿No sería mejor colocarlas en otro lugar donde el usuario no se las encuentre? Al igual que se hace en Mac OS X, donde el contenido de los paquetes .app, que no debería ser visible para el usuario en /Applications, se esconde en las profundidades de /System/Library/…«`.
¿Qué pasa con las dependencias?
Creo que deberíamos de alguna manera indicar las dependencias, ¿verdad? ¿Se puede considerar que Qt es una parte obligatoria de la instalación predeterminada de Haiku? ¡No! Qt no está instalado por defecto. ¿Puede el programa de construcción de paquetes determinar automáticamente las dependencias verificando los archivos ELF? Me dijeron que HaikuPorter efectivamente hace eso, pero package no. Todo porque es simplemente un "constructor de paquetes" que por sí solo solo crea archivos hpkg.
¿Debería hacer Haiku más sofisticado, añadiendo una política que diga que un paquete no debe tener dependencias de paquetes que no estén en haikuports? (Мне бы так хотелось, поскольку подобная политика значительно облегчает задачу — система смогла бы автоматически разрешить зависимости каждого пакета, загружаемого откуда угодно, без возни с дополнительными источниками пакетов).
mr. waddlesplash aclara:
No quisiéramos restringir tanto la libertad de los desarrolladores, ya que es evidente que si CompanyX desea mantener su propio conjunto de software con dependencias (y por lo tanto un repositorio) — está completamente libre de hacerlo.
En tal caso, tal vez valdría la pena recomendar evitar que los paquetes de terceros dependan de algo que no esté en haikuports, empaquetando completamente todo lo necesario con la aplicación. Pero creo que ese es un tema para un artículo futuro en esta serie. [¿El autor se refiere a AppImage? — nota del traductor]
Añadiendo un ícono de aplicación
¿Y si quiero agregar uno de los íconos integrados elegantes a los recursos de mi aplicación recién creada? Resulta que este es un tema sorprendente, así que será el principal para el próximo artículo.
¿Cómo organizar la construcción continua de aplicaciones?
Imagina un proyecto similar a Inkscape (sí, estoy al tanto de que aún no está en Haiku, pero es útil para mostrar). Tienen un repositorio de código fuente. https://gitlab.com/inkscape/inkscape.
Cada vez que alguien registra sus cambios en el repositorio, se activan los pipelines de construcción, y luego las correcciones se prueban automáticamente, la aplicación se empaqueta en varios formatos, incluyendo AppImage para Linux (un paquete de aplicación autónomo que puede ser descargado para pruebas locales sin importar qué esté instalado o no en el sistema). [¡Lo sabía! — Nota del traductor]). De manera similar, todo ocurre con cada solicitud de fusión de ramas, por lo que se puede descargar la aplicación construida a partir del código propuesto en la solicitud de fusión, incluso antes de la fusión.
Las solicitudes de fusión con estados de construcción y la posibilidad de descargar binarios compilados en caso de una construcción exitosa (marcada en verde).
La construcción se inicia en contenedores Docker. GitLab ofrece runners gratuitos en Linux, además creo que es posible conectar runners propios (por cierto, no tengo idea de cómo funcionará esto en sistemas como Haiku, que, según sé, no tienen Docker o su equivalente, pero FreeBSD también carece de Docker, así que este problema no es exclusivo de Haiku).
Idealmente, la construcción de aplicaciones para Haiku podría realizarse dentro de un contenedor Docker para Linux. En ese caso, la construcción para Haiku podría integrarse en los pipelines existentes. ¿Existen cross-compilers? ¿O hay que emular toda Haiku dentro del contenedor Docker utilizando algo como QEMU/KVM (asumiendo que funcione así dentro de Docker)? Por cierto, muchos proyectos usan principios similares. Por ejemplo, Scribus lo hace, ya está disponible para Haiku. Llegará el día en que podré enviar solicitudes de fusión a otros proyectos para agregar soporte para Haiku.
Uno de los desarrolladores aclara:
Para otros proyectos que deseen crear paquetes de forma independiente, se admite el método estándar CMake/CPack. Otros sistemas de compilación pueden ser compatibles si se llama directamente al programa de construcción de paquetes, lo cual es bueno si las personas están interesadas en ello. La experiencia muestra que hasta ahora no ha habido un interés particular, así que haikuporter ha funcionado como nos convenía, pero, en última instancia, ambos métodos deberían funcionar juntos. Debemos presentar un conjunto de herramientas para la compilación cruzada de software desde Linux o cualquier otro sistema operativo de servidor (Haiku no está diseñado para funcionar en servidores).
Aplaudo de pie. Los usuarios comunes de Linux soportan toda esta carga adicional y equipaje extra (seguridad, control estricto, etc.), que es necesario para un sistema operativo de servidor, pero no para uno personal. Por lo tanto, estoy completamente de acuerdo en que la posibilidad de compilar aplicaciones para Haiku en Linux es el camino correcto.
Conclusión
El portado de aplicaciones POSIX a Haiku es posible, pero puede requerir más recursos que una simple recompilación. Definitivamente me quedaría atascado en esto durante mucho tiempo si no fuera por la ayuda de personas en el canal #haiku en la red irc.freenode.net. Pero incluso ellos no siempre veían de inmediato qué estaba mal.
Las aplicaciones escritas en Qt son una ligera excepción. Compilé una sencilla aplicación de demostración sin problemas significativos.
Compilar un paquete para aplicaciones simples también es bastante fácil, pero solo para aquellas "lanzadas de la manera tradicional", es decir, que tienen archivos de código fuente versionados, destinados a ser soportados en haikuports. Para la compilación continua (compilación en cada confirmación de cambios) desde GitHub, no es tan sencillo. Aquí Haiku se siente más parecido a una distribución de Linux que al resultado en macOS, donde al hacer clic en el botón "Compilar" en XCode se obtiene un paquete .app, listo para ser insertado en la imagen del disco .dmg, preparado para ser subido a mi sitio web.
La compilación continua de aplicaciones basada en un sistema operativo "servidor", por ejemplo, Linux, probablemente se hará posible si hay demanda por parte de los desarrolladores, pero actualmente el proyecto Haiku tiene otras tareas más urgentes.
¡Intenta tú mismo! El proyecto Haiku proporciona imágenes para descargar desde DVD o USB, formadas . Para instalar, solo necesitas descargar la imagen y grabarla en un pendrive con
¿Tienes preguntas? Te invitamos a nuestro .
Revisión de errores:
Desde traducción: este es el quinto artículo de la serie sobre Haiku.
Lista de artículos:
Fuente: habr.com
