TL; DR : Débutant a vu Haiku pour la première fois, essayant de porter certains programmes du monde Linux.
Mon premier programme porté par Haiku emballé dans son format hpkg
J'ai récemment découvert Haiku, un système d'exploitation PC étonnamment bon.
Aujourd'hui, je vais apprendre à transférer 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 du développeur pour Linux. Je m'excuse pour les erreurs stupides commises dans le processus, car depuis que j'ai téléchargé Haiku pour la première fois, aucune semaine ne s'est écoulée.
Je veux atteindre trois objectifs:
- Portez une application CLI simple
- Application de port de l'interface graphique vers Qt
- Emballez-les plus tard au format hpkg (puisque je pense toujours à adapter AppDir et AppImage pour Haiku ...)
Commençons. Dans les sections de documentation et de développement , ainsi que dans le wiki 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! Regarder à l'intérieur est effrayant, mais j'espère pour le mieux. Les mots du développeur sont encourageants: «depuis longtemps, parce que BeOS n’était pas compatible POSIX», mais Haiku «pour la plupart» est déjà comme ça.
Portage d'une application CLI simple
La première pensée était de porter l'application avrdude , mais il s'est avéré que cela avait déjà été fait il y a longtemps.
Première tentative: rien à regarder
Ce que je ne peux pas comprendre du tout, c'est que depuis plus de 10 ans, les applications ont été portées sur Haiku - malgré le fait que le système d'exploitation lui-même n'a même pas la version 1.0.
Deuxième tentative: besoin de réécrire
Je vais donc utiliser la ptouch-770 , CLI pour contrôler l'imprimante Brother P-Touch 770, sur laquelle j'imprime des étiquettes.
J'imprime diverses étiquettes dessus, et vous l'avez peut-être déjà vu dans un précédent article. Plus tôt, j'ai écrit un petit programme wrapper avec une interface graphique en Python (car il est sur Gtk +, je vais devoir le réécrire, ce qui est une bonne raison d'apprendre quelque chose).
Imprimante d'étiquettes Brother P-Touch 770. Fonctionne-t-elle sous Haiku?
Le gestionnaire de paquets de Haiku connaît les bibliothèques et les commandes, donc si je reçois le message «ne peut pas trouver libintl» lorsque j'exécute configure , je lance simplement pkgman install devel:libintl et le paquet dont vous avez besoin est trouvé. Similaire à pkgman install cmd:rsync . Eh bien, etc.
Sauf lorsque cela ne fonctionne 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 plein, il n'existe donc pas pour Haiku. Ce qui signifie la nécessité de modifier le code source que j'essaie de compiler.
Eh, vous ne sauterez pas au-dessus de votre tête, et je ne sais même pas par où commencer.
Troisième tentative
Ce serait bien d'avoir tmate pour Haiku, alors je laisserais les développeurs de Haiku se connecter à ma session de terminal - au cas où quelque chose se passerait mal. Les instructions sont assez simples:
./autogen.sh ./configure make make install
Il 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 cherche des curses .
Quelque chose a été trouvé, ce qui m'a donné un indice pour une demande 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 allé à HaikuDepot, et, bien sûr, trouvé devel:msgpack_c_cpp_devel . Quel genre de 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 nécessaire pour une simple reconstruction.
J'ai parlé avec des développeurs Haiku sympathiques, il s'est avéré qu'il y avait une erreur dans msgpack, et après quelques minutes, je vois un patch, dans HaikuPorts. J'observe personnellement comment un package fixe est construit ici (buildslave - machines virtuelles).
Construire un msgpack fixe sur buildmaster
En attendant, envoyez le patch en amont pour ajouter la prise en charge de Haiku à msgpack .
Cinq minutes plus tard, le msgpack mis à jour est déjà disponible sur 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. J'ai dit ça?!
Pour revenir à la tâche d'origine:
/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 n'est pas coupable. IMAXLABEL dans tty.c comme ceci:
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.
Eh bien, encore une fois ... Au fait:
/Haiku/home/tmate> ./configure | grep -i OPENAT checking for openat... no
mr. waddlesplash 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 présenté config.log .
Ils m'ont expliqué qu'il y avait autre chose dans libnetwork à libresolv sur Haiku. Il est très probablement nécessaire de modifier davantage le code. Je dois penser ...
find . -type f -exec sed -i -e 's|lresolv|lnetwork|g' {} \;
La question éternelle: ce qui se passe.
/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
Le même, seulement de profil. Googlé et l'a trouvé . Si l'ajout de -lssp "parfois" aide, j'essaye:
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp" (...)/Haiku/home/tmate> make (...)/Haiku/home/tmate> ./tmate
Ouah! Ça commence! Mais ...
[tmate] ssh.tmate.io lookup failure. Retrying in 2 seconds (non-recoverable failure in name resolution)
Je vais essayer de déboguer le fichier ici :
/Haiku/home/tmate> strace -f ./tmate >log 2>&1
"Bad port ID", c'est déjà comme une carte de visite haiku . Peut-être que quelqu'un imagine ce qui ne va pas et comment y remédier? Si quoi que ce soit, je mettrai à jour l'article. Lien vers GitHub .
Portage d'une application GUI vers 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 où commencer? Il n'y a pas de documentation simple, je vais sur la chaîne #haiku sur irc.freenode.net et j'entends:
- La commande
package est un moyen de bas niveau de créer des packages. Pour la plupart, PackageInfo est suffisant pour cela, comme décrit dans la section "Transformer en un package .hpkg approprié" - J'ai besoin de faire quelque chose comme ça
- Vous pouvez utiliser hpkg-creator (il plante, rapport d'erreur )
On ne sait pas quoi faire. Je suppose que j'ai besoin d'un guide pour débutants dans le style de "Hello World!", Idéalement une vidéo. Ce serait bien d'avoir une introduction pratique à HaikuPorter, comme dans GNU bonjour.
J'ai lu ce qui suit:
haikuporter est un outil pour créer des projets batch partagés pour Haiku. Il utilise le référentiel HaikuPorts comme base pour tous les packages. Pour créer des packages, des recettes haikuporter sont utilisées.
De plus, je découvre que:
Pas besoin de conserver les recettes dans le coffre HaikuPorts. Vous pouvez créer un autre référentiel, y mettre des recettes, puis pointer haikuporter vers celui-ci.
Juste ce dont j'ai besoin - si vous ne cherchez pas un moyen de publier publiquement le colis. Mais c'est un sujet pour un autre article.
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 recettes
QtQuickApp-1.0.recipe fichier sous QtQuickApp-1.0.recipe , puis aikuporter -S ./QuickApp-1.0.recipe . Les dépendances sont vérifiées pour tous les packages dans le référentiel haikuports , ce qui prend un certain temps. Je vais chercher du café.
Et pourquoi cette vérification devrait-elle être effectuée sur ma machine locale, et non de manière centralisée sur le serveur 1 fois pour tout le monde?
Selon m. waddlesplash:
Avec de telle sorte que vous pouvez réécrire n'importe quel fichier dans le référentiel;) Vous pouvez légèrement l'optimiser en calculant les informations nécessaires lorsque cela est nécessaire, car les dernières modifications 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'aucun fichier de recette ordinaire ne contient le code source de votre application. Vous devez le conserver dans le 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 lourd. Je n'aime pas vraiment ça, mais je pense que c'est nécessaire pour qu'au final, 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 git commit pour une intégration continue? (Le développeur confirme: "Rien n'en sortira. Les recettes sont conçues pour être relativement stables.")
Pour le plaisir, ajoutez à la recette:
CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"
Toujours pas content:
~/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 le dépôt git, le code est déjà là directement, il n'y a rien à décompresser. De mon point de vue, l'outil devrait être suffisamment intelligent pour ne pas chercher le décompresseur s'il est au-dessus de l'URL avec 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, et pourquoi tout est si compliqué, pourquoi ne pouvez-vous pas simplement "travailler"? Au final, il n'est pas si rare de construire quelque chose avec GitHub. Soit les outils fonctionnent immédiatement, sans avoir besoin de personnalisation, ou comme je l'appelle "chichi".
Peut-être que cela fonctionnera comme ceci:
SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"
Non. Toujours avoir cette erreur stupide et faire comme décrit ici
sed -i -e 's|#ALLOW_UNSAFE_SOURCES|ALLOW_UNSAFE_SOURCES|g' /boot/home/config/settings/haikuports.conf
Je vais un peu plus loin, mais pourquoi me crie-t-il (GitHub n'est pas sûr!) Et essaie toujours de déballer quelque chose.
Selon m. waddlesplash :
Eh bien, oui, la raison était la volonté de vérifier l'intégrité des données obtenues pour l'assemblage. Une option consiste à vérifier la somme de contrôle de l'archive, mais vous pouvez bien sûr également hacher des fichiers individuels, qui ne seront pas implémentés, car cela prend beaucoup plus de temps. La conséquence de ceci est «l'insécurité» de git et d'autres VCS. Très probablement, ce sera toujours le cas, car la création d'une archive sur GitHub est assez facile et souvent plus rapide. Eh bien, à l'avenir, le message d'erreur ne sera peut-être pas 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
Comme d'habitude, je vais demander à de bonnes personnes sur la chaîne #haiku sur le réseau irc.freenode.net. Et où suis-je sans eux? Après l'invite, j'ai réalisé que je devrais utiliser:
srcGitRev="d0769f53639eaffdcd070bddfb7113c04f2a0de8" SOURCE_URI="https://github.com/probonopd/QtQuickApp/archive/$srcGitRev.tar.gz" SOURCE_DIR="QtQuickApp-$srcGitRev" CHECKSUM_SHA256="db8ab861cfec0ca201e9c7b6c0c9e5e828cb4e9e69d98e3714ce0369ba9d9522"
Eh bien, il est devenu clair ce qu'il faisait - il téléchargeait l'archive avec les sources d'une certaine révision. C'est stupide, de mon point de vue, et pas tout à fait ce que je voulais, à savoir, télécharger la dernière révision de la branche master.
L'un des développeurs l'a expliqué de cette façon:
Nous avons notre propre CI, donc tout ce qui est placé dans le référentiel haikuports sera sécurisé pour tous les utilisateurs, et nous ne voulons pas risquer de collecter et de livrer "toute la dernière version en amont".
J'ai compris! Dans tous les cas, cela s'est produit:
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 cet ad infinitum. Apparemment, c'est une erreur (y a-t-il une application? Je ne l'ai pas trouvée).
Avec haikuporter et le référentiel haikuports , vous ne sentez pas que le niveau "fonctionne", mais en tant que développeur, j'aime certaines choses à travailler avec Haiku. Pour la plupart, cela est similaire à l'Open Build Service - un ensemble d'outils pour construire des assemblys Linux: extrêmement puissant, avec une approche systématique, mais redondant pour ma petite application hello world.
Encore une fois, selon m. waddlesplash:
En effet, HaikuPorter est très strict par défaut (en plus il y a le mode lint, ainsi que le mode strict, ce qui le rend encore plus strict!), Mais uniquement parce qu'il crée des packages qui fonctionnent, et pas seulement des packages. Par conséquent, il jure sur les dépendances non déclarées, les bibliothèques non importées correctement, les versions incorrectes, etc. Le but est de détecter tous les problèmes sans exception, y compris les futurs, avant que l'utilisateur ne s'en rende compte (par conséquent, il n'a pas été possible d'installer avrdude, car la dépendance était effectivement indiquée dans la recette). Les bibliothèques ne sont pas seulement des packages séparés ou même des versions non définies de SO. HaikuPorter garantit que tout cela est suivi dans les recettes pour éviter les erreurs d'exécution.
En principe, ce niveau de rigueur est justifié lors de la création du système d'exploitation, mais il me semble inutile pour l'application hello world. J'ai décidé d'essayer autre chose.
Peut - être que cette simple instruction me conviendrait mieux?
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
D'une rapidité inattendue, d'une simplicité inattendue, d'une efficacité inattendue. Juste comme je l'aime, incroyable!
Installation - quoi et où?
Déplacement du fichier QtQuickApp.hpkg vers ~/config/packages à l'aide du gestionnaire de fichiers, après quoi QtQuickApp est apparu comme par magie dans ~/config/apps .
Encore une fois, d'une rapidité inattendue, simple et efficace. Incroyable, incroyable!
Mais ... (où sans eux!)
L'application n'est toujours pas dans la liste du menu des applications et dans 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, l'instruction) manqué 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, /data/deskbar/menu/Applications/…
Eh bien, et que dois-je y mettre? Et bien ...
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 fera l'affaire, mais des questions demeurent: pourquoi est-elle nécessaire, à quoi sert-elle? À mon avis, cela détruit l'impression générale que le système est si sophistiqué.
Comme l'explique mr. waddlesplash:
Parfois, il existe des applications dont d'autres applications ont besoin, mais pas dans le menu. Par exemple, LegacyPackageInstaller dans votre capture d'écran qui traite les archives .pkg au format BeOS. Je veux que les utilisateurs les définissent, mais leur présence dans le menu entraînera de la confusion.
Pour une raison quelconque, il me semble qu'il existe une solution plus simple, par exemple Hidden=true dans les fichiers Linux .desktop . Pourquoi ne pas faire des informations «cachées» une ressource et un attribut du système de fichiers?
Ce qui n'est pas particulièrement sophistiqué, c'est le nom de l'application (certaine) qui affiche le menu, la deskbar , est étroitement lié le long du chemin.
mr. waddlesplash à cette occasion explique:
"Deskbar" dans ce cas doit être compris comme une sorte de terme général (approximativement le même que "taskbar", se référant à la fois à l'application Windows et au concept général). Eh bien, puisque c'est une deskbar , pas une "barre de deskbar ", cela peut également ê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 y en a-t-il un dans mon QtQuickApplication et pas dans l'autre? (Après tout, ce n'est pas un système, mais le deuxième utilisateur, que je comprendrais personnellement).
Je suis vraiment confus et je pense que nous devons unifier cela.
Commentaire mr. waddlesplash
Dans le répertoire des applications, il y a des applications qui ne sont pas nécessaires dans le menu. Mais la situation avec le menu doit vraiment être améliorée, pour le rendre plus personnalisable.
Application, ou cela ne se produira pas;)
J'ai pensé: est-il vraiment nécessaire de placer des applications dans /system/apps , si les utilisateurs les voient là-bas - ce n'est pas souhaitable. Peut-être vaut-il mieux les placer dans un autre endroit où l'utilisateur ne les rencontrera pas? Tout comme cela a été fait sur Mac OS X, où le contenu des packages .app , qui ne devrait pas être visible pour l'utilisateur dans /Applications , est caché dans les entrailles de / System / Library / ... ''.
Et les dépendances?
Je pense qu'il vaut la peine de souligner les dépendances en quelque sorte, non? Qt peut-il être considéré comme une partie obligatoire de l'installation Haiku par défaut? Non! Qt n'est pas installé par défaut. Un programme de construction de packages peut-il détecter automatiquement les dépendances en vérifiant les fichiers ELF? On m'a dit que HaikuPorter le faisait vraiment, mais pas le package . En effet, il n'est qu'un " hpkg packages", qui en lui-même crée simplement des fichiers hpkg .
Haiku devrait-il être plus raffiné en ajoutant une politique selon laquelle un package ne devrait pas avoir de dépendances sur des packages non inclus dans les haikuports ? (Je voudrais tellement, car une telle politique rend la tâche beaucoup plus facile - le système serait en mesure de résoudre automatiquement les dépendances de chaque package téléchargé de n'importe où, sans se soucier de sources de package supplémentaires).
mr. waddlesplash explique:
, , ( ) — .
-, haikuports, . , , . [ AppImage? — . traducteur]
? , , .
?
, Inkscape (, , Haiku, ). https://gitlab.com/inkscape/inkscape .
, - , , , , , AppImage Linux ( , , , [ ! — . ] ). , , , , .
( )
Docker. GitLab runners Linux, , runners (, , Haiku, , , Docker , FreeBSD Docker, Haiku).
Haiku Docker Linux. Haiku . ? Haiku Docker, - QEMU/KVM ( , Docker)? , . , Scribus — Haiku. , , Haiku.
:
, , CMake/CPack. , , , . : , haikuporter , , , . Linux (Haiku ).
. Linux (, ..), , . , Haiku Linux — .
Conclusion
POSIX Haiku , , . , #haiku irc.freenode.net. , .
, Qt, — . .
, " ", .. , haikuports. ( ) GitHub . Haiku Linux, Mc, "" XCode .app , .dmg , .
"" , , Linux, , , Haiku , .
Essayez-le vous-même! Après tout, le projet Haiku fournit des images de téléchargement quotidiennes à partir d'un DVD ou d'une clé USB. Pour l'installer, il suffit de télécharger l'image et de l'écrire sur une clé USB à l'aide d' Etcher
Vous avez une question? Nous vous invitons à la chaîne de télégramme en russe.
Aperçu des bogues: comment se tirer une balle dans le pied en C et C ++. Collection de recettes Haiku OS
: Haiku.
: