Mon cinquième jour avec Haiku : portons quelques programmes

TL; DR: Un débutant a vu Haiku pour la première fois, essayant de porter certains programmes du monde Linux.

Mon premier programme porté Haiku, packagé dans son format hpkg

Récemment J'ai découvert Haiku, un système d'exploitation étonnamment bon pour PC.
Aujourd'hui, je vais apprendre à porter de nouveaux programmes sur ce système d'exploitation. L'objectif principal est une description de la première expérience de passage à Haiku du point de vue d'un développeur Linux. Je m'excuse pour les erreurs stupides que j'ai commises en cours de route, car cela ne fait même pas une semaine depuis que j'ai téléchargé Haiku pour la première fois.

Je veux atteindre trois objectifs :

• Portez une simple application CLI
• Portez une application de l'interface graphique vers Qt
• Ensuite, emballez-les au format hpkg (puisque je pense toujours à adapter AppDir et AppImage pour Haiku...)

Commençons. En rubriques documentation и développement, ainsi que dans wiki Depuis HaikuPorts, j'ai trouvé la bonne direction. Il existe même un livre PDF en ligne BeOS : Portage d'une application Unix.
467 pages - et cela date de 1997 ! C'est effrayant de regarder à l'intérieur, mais j'espère que tout ira pour le mieux. Les propos du développeur sont encourageants : « cela a pris beaucoup de temps car BeOS n'était pas conforme à POSIX », mais Haiku « pour la plupart » est déjà comme ça.

Portage d'une simple application CLI

La première idée a été de porter l'application avrude, mais il s'est avéré que c'est déjà avoir fait il y a longtemps.

Premier essai : rien à regarder

Ce que je n'arrive pas à comprendre, c'est que c'est déjà le cas Les applications sont portées sur Haiku depuis plus de 10 ans - malgré le fait que le système d'exploitation lui-même n'est même pas encore la version 1.0.

Deuxième tentative : il faut réécrire

Je vais donc utiliser ptouch-770, CLI pour contrôler l'imprimante Brother P-Touch 770 que j'utilise pour imprimer des étiquettes.
J'imprime diverses étiquettes dessus, et vous l'avez peut-être déjà vu dans l'article précédent. Un peu plus tôt, j'ai écrit un petit programme wrapper GUI en Python (comme il est en Gtk+, il faudra le réécrire, et c'est une bonne raison d'apprendre).

Imprimante d'étiquettes Brother P-Touch 770. Est-ce que ça fonctionnera avec Haiku ?

Le gestionnaire de paquets Haiku connaît les bibliothèques et les commandes, donc si je reçois un message « Impossible de trouver libintl » lors de l'exécution configure - je viens de me lancer pkgman install devel:libintl et le package requis sera trouvé. De même pkgman install cmd:rsync. Eh bien, etc.

Sauf quand ça ne marche pas :

/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

Peut-être que udev est trop basé sur Linux et n'existe donc pas pour Haiku. Ce qui signifie que je dois modifier le code source que j'essaie de compiler.
Eh, tu ne peux pas sauter par-dessus la tête, et je ne sais même pas par où commencer.

Troisième tentative

Ce serait bien d'avoir tmate pour Haiku, j'autoriserais les développeurs Haiku à se connecter à ma session de terminal - en cas de problème. Les instructions sont assez simples :

./autogen.sh
./configure
make
make install

Ça a l’air bien, alors pourquoi ne pas l’essayer sur 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

Dans cette étape, j'ouvre HaikuDepot et recherche curses.
Quelque chose a été trouvé, ce qui m'a donné une indication pour une requête plus compétente :

/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

Encore une fois, je suis allé sur HaikuDepot et, bien sûr, j'ai trouvé devel:msgpack_c_cpp_devel. Quels sont ces noms étranges ?

/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

À cette étape, j'ai réalisé que le portage d'un programme vers Haiku nécessite beaucoup plus de connaissances que ce qui est nécessaire pour une simple reconstruction.
J'ai parlé aux sympathiques développeurs de Haiku, il s'avère qu'il y a un bug dans msgpack, et après quelques minutes, je vois un patch dans HaikuPorts. Je peux voir de mes propres yeux comment le paquet corrigé je vais ici (buildslave - machines virtuelles).

Construire le msgpack corrigé sur buildmaster

Entre temps, j'envoie un patch en amont pour ajouter le support Haiku à msgpack.

Cinq minutes plus tard, le msgpack mis à jour est déjà 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.

Étonnamment bon. Est-ce que j'ai dit ca?!

Je reviens au problème initial :

/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

Il semble maintenant que msgpack ne soit pas en faute. je commente IMAXLABEL в tty.c comme suit:

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

Résultat:

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.

Bon, c'est reparti... Au fait :

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

M. dandinement vous indique où creuser :

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

Ici j'ai posté config.log.

Ils m'ont expliqué qu'il y avait autre chose dans libnetwork en plus de libresolv sur Haiku. Apparemment, le code doit être modifié davantage. Besoin de penser…

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

L’éternelle question : que se passe-t-il ?

/Haiku/home/tmate> ./configure LDFLAGS="-lbsd"
(...)/Haiku/home/tmate> make
(...)
# Success!# Let's run it:/Haiku/home/tmate> ./tmate
runtime_loader: /boot/system/lib/libssh.so.4.7.2: Could not resolve symbol '__stack_chk_guard'
resolve symbol "__stack_chk_guard" returned: -2147478780
runtime_loader: /boot/system/lib/libssh.so.4.7.2: Troubles relocating: Symbol not found

La même chose, seulement de profil. Googlé et j'ai trouvé ça. Si vous ajoutez -lssp « parfois » aide, j'essaie :

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

Ouah! Il commence! Mais…

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

je vais essayer de déboguer déposer ici:

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

« Bad port ID » est déjà comme une carte de visite haïku. Peut-être que quelqu'un a une idée de ce qui ne va pas et comment y remédier ? Si c'est le cas, je mettrai à jour l'article. Lié à GitHub.

Portage de l'application GUI sur Qt.

Je choisis une application QML simple.

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

Vraiment simple. Moins d'une minute!

Emballage d'applications dans hpkg à l'aide de haikuporter et haikuports.

Par quoi dois-je commencer ? Il n'y a pas de documentation simple, je vais sur le canal #haiku sur irc.freenode.net et j'entends :

• Équipe package - un moyen de bas niveau pour créer des packages. Pour l'essentiel, PackageInfo lui suffit, comme décrit dans la section « En faire un package .hpkg approprié »
• J'ai besoin de faire quelque chose est
• Peut utiliser créateur de hpkg (ça plante pour moi, rapport d'erreur)

On ne sait pas quoi faire. Je suppose que j'ai besoin d'un guide du débutant de style Hello World, idéalement une vidéo. Ce serait bien d'avoir également une introduction pratique à HaikuPorter, comme cela se fait dans GNU hello.

Je lis ce qui suit :

haikuporter est un outil permettant de créer des projets de packages communs pour Haiku. Il utilise le référentiel HaikuPorts comme base pour tous les packages. Les recettes Haikuporter sont utilisées pour créer des packages.

De plus, je découvre que :

Il n'est pas nécessaire de stocker les recettes dans le stockage HaikuPorts. Vous pouvez créer un autre référentiel, y mettre les recettes, puis y pointer haikuporter.

Juste ce dont j'ai besoin - si je ne cherche pas un moyen de publier le package publiquement. Mais c'est un sujet pour un autre post.

Installer haikuporter et 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

Écrire une recette

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
}

Assemblage de la recette

J'enregistre le fichier sous le nom QtQuickApp-1.0.recipe, après quoi je lance aikuporter -S ./QuickApp-1.0.recipe. Les dépendances sont vérifiées pour tous les packages du référentiel haïkuports, ce qui prend du temps. Je vais prendre un café.

Pourquoi diable cette vérification devrait-elle être effectuée sur ma machine locale, et non de manière centralisée sur le serveur, une fois pour tout le monde ?

Selon M. dandinement :

Avec tel que vous pouvez réécrire n'importe quel fichier dans le référentiel 😉 Vous pouvez optimiser cela un peu, en calculant les informations nécessaires en cas de besoin, car les dernières modifications apportées sont assez rares.

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

Il s'avère qu'il n'existe pas de fichier de recette standard contenant le code source de votre application. Vous devez le conserver dans un référentiel au format HaikuPorts.

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

Ce fait rend l'assemblage plus encombrant. Je ne l'aime pas particulièrement, mais je pense que c'est nécessaire pour qu'à terme tous les logiciels open source apparaissent dans HaikuPorts.

J'obtiens ce qui suit :

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

Qu'est-ce qui ne va pas? Après avoir lu irc, je fais :

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

Une question intéressante s'est posée. Si j'ajoute une somme de contrôle à la recette, correspondra-t-elle au dernier commit git pour une intégration continue ? (Le développeur confirme : "Ça ne marchera pas. Les recettes sont conçues pour être relativement stables.")

Pour le plaisir, ajoutez à la recette :

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Toujours pas satisfait :

~/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 fait-il? Après tout, c'est un dépôt git, le code est déjà là directement, il n'y a rien à déballer. De mon point de vue, l'outil devrait être suffisamment intelligent pour ne pas rechercher de décompresseur s'il se trouve au-dessus de l'URL GitHub.

Peut-être que uri git:// fonctionnera

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

Maintenant, il se plaint comme ceci :

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

Hmm, pourquoi tout est si compliqué, pourquoi ne peux-tu pas « juste travailler » ? Après tout, il n'est pas rare de créer quelque chose à partir de GitHub. Qu'il s'agisse d'outils qui fonctionnent immédiatement, sans nécessiter de configuration, ou comme je l'appelle « s'embêter ».

Peut-être que cela fonctionnera comme ceci :

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

Non. J'ai toujours cette erreur étrange et je le fais, comme décrit ici

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

J'avance un peu plus loin, mais pourquoi me crie-t-il dessus (GitHub n'est pas sécurisé !) et essaie-t-il toujours de déballer quelque chose.

selon M. dandinement:

Eh bien, oui, la raison était le désir de vérifier l'intégrité des données reçues pour l'assemblage. L'une des options consiste à vérifier la somme de contrôle de l'archive, mais vous pouvez bien sûr hacher des fichiers individuels, qui ne seront pas implémentés, car cela prend beaucoup plus de temps. La conséquence en est « l’insécurité » de git et des autres VCS. Ce sera probablement toujours le cas, car créer une archive sur GitHub est assez simple et souvent plus rapide. Eh bien, à l'avenir, peut-être que le message d'erreur ne sera plus aussi flashy... (nous ne fusionnons plus de telles recettes dans 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

Par vieille habitude, je vais interroger les bonnes personnes sur la chaîne #haiku du réseau irc.freenode.net. Et où serais-je sans eux ? Après l'indice, j'ai réalisé que je devais utiliser :

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

D'accord, ce qu'il fait est devenu clair : il télécharge une archive avec le code source d'une certaine révision. C’est stupide, de mon point de vue, et pas exactement ce que je voulais, à savoir télécharger la dernière révision depuis la branche master.

L'un des développeurs l'a expliqué ainsi :

Nous avons notre propre CI, donc tout ce qui est placé dans le référentiel haikuports sera packagé pour tous les utilisateurs, et nous ne voulons pas risquer de collecter et de fournir « tout dans la dernière version en amont ».

Compris! En tout cas, voici ce qui s'est passé :

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

Il répète cela à l’infini. Apparemment, il s’agit d’une erreur (y a-t-il une application ? Je ne l’ai pas trouvée).

С haikuporter et dépôt haïkuports Il n'y a pas de sentiment de « ça marche », mais en tant que développeur, il y a certaines choses que j'aime dans le fait de travailler avec Haiku. Pour l'essentiel, il est similaire à l'Open Build Service, un ensemble d'outils permettant de créer des builds Linux : extrêmement puissant, avec une approche systématique, mais excessif pour ma petite application "hello world".

Encore une fois, selon m. dandinement :

En effet, HaikuPorter est assez strict par défaut (en plus il existe un mode lint ainsi qu'un mode strict pour le rendre encore plus strict !), mais uniquement parce qu'il crée des packages qui fonctionneront, plutôt que de simplement créer des packages. C'est pourquoi il se plaint de dépendances non déclarées, de bibliothèques mal importées, de versions incorrectes, etc. Le but est de détecter tous les problèmes, y compris les futurs, avant que l'utilisateur n'en soit informé (c'est pourquoi il n'a pas été possible d'installer avrdude, car la dépendance était en fait spécifiée dans la recette). Les bibliothèques ne sont pas simplement des packages individuels ou même des versions SO spécifiques. HaikuPorter veille à ce que tout cela soit respecté dans les recettes elles-mêmes pour éviter les erreurs lors de l'exécution.

En principe, ce niveau de rigueur est justifié lors de la création d'un système d'exploitation, mais il me semble inutile pour une application « hello world ». J'ai décidé d'essayer autre chose.

Création d'applications au format hpkg à l'aide de la commande « package create »

Peut-être ceci Des instructions simples fonctionneront-elles mieux pour moi ?

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

Étonnamment rapide, étonnamment simple, étonnamment efficace. Exactement comme je l’aime, incroyable !

Installation – quoi et où ?

Déplacement du fichier QtQuickApp.hpkg vers ~/config/packagesà l'aide d'un gestionnaire de fichiers, après quoi QtQuickApp est apparu comme par magie dans ~/config/apps.
Encore une fois, étonnamment rapide, simple et efficace. Incroyable, incroyable !

Mais... (où serions-nous sans eux !)

L'application est toujours absente de la liste du menu des applications et de QuickLaunch. Je pense que je sais déjà comment y remédier. Dans le gestionnaire de fichiers, je déplace QtQuickApp.hpkg de ~/config/packages vers /system/packages.

Non, toujours porté disparu. Apparemment, j'ai (enfin, ainsi que les instructions) raté quelque chose.

Après avoir regardé l'onglet "Contenu" dans HaikuDepot pour d'autres applications, j'ai vu qu'il y avait des fichiers comme /data/mimedb/application/x-vnd... ce qui est encore plus remarquable, c'est /data/deskbar/menu/Applications/….

Eh bien, que dois-je y mettre ? Allez...

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

Je suis sûr que cette astuce fonctionnera, mais des questions demeurent : pourquoi est-ce nécessaire, à quoi ça sert ? Je pense que cela gâche l’impression générale selon laquelle le système est si sophistiqué.

Comme l'explique M. dandinement :

Parfois, il existe des applications dont d'autres applications ont besoin mais qui ne figurent pas dans le menu. Par exemple, LegacyPackageInstaller dans votre capture d'écran, traitant les archives .pkg au format BeOS. J'aimerais que les utilisateurs les installent, mais leur présence dans le menu prêtera à confusion.

Pour une raison quelconque, il me semble qu'il existe une solution plus simple, par exemple Hidden=true dans les fichiers .desktop sous Linux. Pourquoi ne pas faire des informations « cachées » une ressource et un attribut du système de fichiers ?

Ce qui n'est surtout pas subtil, c'est le nom de (certaines) applications qui affiche le menu, deskbar, solidement attaché en cours de route.

M. waddlesplash explique ceci :

« Barre de bureau » dans ce cas doit être compris comme une sorte de terme général (à peu près de la même manière que « barre des tâches », qui fait référence à la fois à l'application Windows et au concept général). Eh bien, puisque cela deskbar, et non « Deskbar », cela peut aussi être compris de la même manière.

2 répertoires "presque identiques" contenant des applications

Pourquoi y a-t-il 2 répertoires avec des applications, et aussi pourquoi mon QtQuickApplication se trouve-t-il dans l'un, mais pas dans l'autre ? (Après tout, il ne s'agit pas d'un système, mais d'un deuxième utilisateur, ce qui me serait personnellement compréhensible).
Je suis vraiment confus et je pense que cela devrait être unifié.

commentaire de M. dandinement

Le catalogue d'applications contient des applications qui ne sont pas nécessaires dans le menu. Mais la situation du menu doit vraiment être améliorée, pour le rendre plus personnalisable.

Candidature, sinon ça n'arrivera pas 😉

Je me demandais : est-il vraiment nécessaire d'héberger des applications dans /system/apps, si les utilisateurs les voient là-bas, ce n'est pas souhaitable. Peut-être serait-il préférable de les placer dans un autre endroit où l'utilisateur ne les rencontrera pas ? Tout comme cela se fait sous Mac OS X, où le contenu des packages .app, qui ne doit pas être visible par l'utilisateur dans /Applications, caché dans les profondeurs de /System/Library/…“`.

Et les dépendances ?

Je pense que cela vaut la peine de spécifier les dépendances d'une manière ou d'une autre, n'est-ce pas ? Qt peut-il être considéré comme une partie obligatoire de l’installation de Haiku par défaut ? Non! Qt n'est pas installé par défaut. Un générateur de packages peut-il détecter automatiquement les dépendances en vérifiant les fichiers ELF ? On m'a dit que HaikuPorter faisait réellement cela, mais package Non. C'est parce qu'il s'agit simplement d'un "constructeur de packages" qui crée simplement des fichiers tout seul. hpkg.

Haiku devrait-il être rendu plus sophistiqué en ajoutant une politique selon laquelle un paquet ne doit pas avoir de dépendances avec des paquets extérieurs à Haiku ? haikuports? (J'aimerais bien, car une telle politique rendrait les choses beaucoup plus faciles - le système serait capable de résoudre automatiquement les dépendances de chaque package téléchargé de n'importe où, sans se soucier des sources de packages supplémentaires.)

M. Waddlesplash explique :

Nous ne voudrions pas autant limiter la liberté des développeurs, car il est évident que si CompanyX souhaite prendre en charge son propre ensemble de logiciels avec des dépendances (et donc un référentiel), elle le fera en toute liberté.

Dans ce cas, il peut être utile de recommander aux packages tiers d'éviter les dépendances sur tout ce qui n'est pas inclus dans haikuports en emballant complètement tout ce qui est nécessaire avec l'application. Mais je pense que c'est un sujet pour un prochain article de cette série. [L'auteur se dirige-t-il vers AppImage ? - environ. traducteur]

Ajout d'une icône d'application

Que faire si je souhaite ajouter l'une des icônes intégrées aux ressources de ma nouvelle application ? Il s’avère que c’est un sujet étonnant, ce sera donc la base du prochain article.

Comment organiser des builds d’applications continus ?

Imaginez un projet comme Inkscape (oui, je suis conscient qu'il n'est pas encore disponible en Haiku, mais c'est pratique de l'afficher dessus). Ils ont un référentiel de code source https://gitlab.com/inkscape/inkscape.
Chaque fois que quelqu'un valide ses modifications dans le référentiel, des pipelines de construction sont lancés, après quoi les modifications sont automatiquement testées, créées et l'application regroupée dans divers packages, y compris AppImage pour Linux (un package d'application autonome qui peut être téléchargé pour des tests locaux indépendamment du ce qui peut ou non être installé sur le système [Je le savais! - environ. traducteur]). La même chose se produit avec chaque demande de fusion de branche, vous pouvez donc télécharger l'application créée à partir du code proposé dans la demande de fusion avant la fusion.

Fusionner les requêtes avec les statuts de build et la possibilité de télécharger les binaires compilés si la build réussit (marqués en vert)

La build s'exécute dans des conteneurs Docker. GitLab propose des exécuteurs gratuits sur Linux, et je pense qu'il pourrait être possible d'inclure vos propres exécuteurs (d'ailleurs, je ne vois pas comment cela fonctionnerait pour des systèmes comme Haiku, qui, je le sais, n'ont pas Docker ou équivalent, mais également pour FreeBSD, il n'y a pas de Docker, donc ce problème n'est pas propre à Haiku).

Idéalement, les applications Haiku peuvent être créées dans un conteneur Docker pour Linux. Dans cette situation, l’assemblage pour Haiku peut être introduit dans des pipelines existants. Existe-t-il des compilateurs croisés ? Ou devrais-je émuler tout Haiku dans un conteneur Docker en utilisant quelque chose comme QEMU/KVM (en supposant que cela fonctionnera de cette façon dans Docker) ? À propos, de nombreux projets utilisent des principes similaires. Par exemple, Scribus fait cela – il est déjà disponible pour Haiku. Un jour, le jour viendra où je pourrai envoyer tel Tirez des requêtes vers d'autres projets pour ajouter la prise en charge de Haiku.

L'un des développeurs explique :

Pour les autres projets souhaitant créer eux-mêmes des packages, la méthode CMake/CPack standard est prise en charge. D'autres systèmes de build peuvent être pris en charge en appelant directement le programme de build du paquet, ce qui est très bien si cela intéresse les gens. L'expérience montre : jusqu'à présent, il n'y a pas eu beaucoup d'intérêt, donc haikuporter a fonctionné comme cela nous convenait, mais, en fin de compte, les deux méthodes devraient fonctionner ensemble. Nous devrions introduire un ensemble d'outils permettant de créer des logiciels à partir de Linux ou de tout autre système d'exploitation serveur (Haiku n'est pas conçu pour fonctionner sur des serveurs).

Je fais une standing ovation. Les utilisateurs réguliers de Linux transportent toute cette charge supplémentaire et ce bagage supplémentaire (sécurité, contrôle strict, etc.) qui sont nécessaires pour un système d'exploitation serveur, mais pas pour un système personnel. Je suis donc entièrement d’accord sur le fait que pouvoir créer des applications Haiku sur Linux est la voie à suivre.

Conclusion

Le portage d'applications POSIX vers Haiku est possible, mais peut être plus coûteux qu'une reconstruction classique. Je serais certainement coincé avec ça pendant longtemps sans l'aide des gens de la chaîne #haiku sur le réseau irc.freenode.net. Mais même eux n’ont pas toujours immédiatement compris ce qui n’allait pas.

Les applications écrites en Qt constituent une exception facile. J'ai mis en place une application de démonstration simple sans aucun problème.

Construire un package pour des applications simples est également assez simple, mais uniquement pour celles « traditionnellement publiées », c'est-à-dire avoir des archives de code source versionnées destinées à être prises en charge dans les haikuports. Pour une build continue (build pour chaque commit de modifications) avec GitHub, tout ne semble pas si simple. Ici, Haiku ressemble plus à une distribution Linux qu'au résultat sur un Mac, où lorsque vous cliquez sur le bouton « Construire » dans XCode, vous obtenez un package .app, prêt à être inséré dans une image disque .dmg, préparé pour téléchargement sur mon site Web.
La création continue d'applications basées sur un système d'exploitation « serveur », par exemple Linux, deviendra très probablement possible s'il y a une demande des développeurs, mais pour le moment, le projet Haiku a d'autres tâches plus urgentes.

Essayez-le vous-même ! Après tout, le projet Haiku fournit des images pour démarrer à partir d'un DVD ou d'une clé USB, générées tous les jours. Pour l'installer, téléchargez simplement l'image et écrivez-la sur un lecteur flash en utilisant Etcher

Avez-vous des questions? Nous vous invitons à la langue russe canal de télégramme.

Aperçu des erreurs : Comment se tirer une balle dans le pied en C et C++. Collection de recettes Haiku OS

À partir de l'auteur traduction : ceci est le cinquième article de la série sur le haïku.

Liste des articles : première La seconde Третья Quatrième

Source: habr.com