TL; DR : O Beginner viu o Haiku pela primeira vez, tentando portar alguns programas do mundo Linux.
Meu primeiro programa portado Haiku empacotado em seu formato hpkg
Eu descobri recentemente o Haiku, um sistema operacional para PC inesperadamente bom.
Hoje vou aprender a transferir novos programas para este sistema operacional. O foco principal é uma descrição da primeira experiência de mudança para o Haiku do ponto de vista do desenvolvedor para Linux. Peço desculpas pelos erros estúpidos cometidos no processo, afinal, desde a primeira vez que baixei o Haiku, não passou uma semana.
Eu quero alcançar três objetivos:
- Portar um aplicativo CLI simples
- Aplicativo de porta da GUI para o Qt
- Empacote-os posteriormente no formato hpkg (já que ainda estou pensando em adaptar o AppDir e o AppImage para Haiku ...)
Vamos começar. Nas seções de documentação e desenvolvimento , bem como no wiki do HaikuPorts , encontrei a direção certa. Existe até um livro em PDF online BeOS: Portando um aplicativo Unix .
467 páginas - e isso é de 1997! Olhar para dentro é assustador, mas espero o melhor. As palavras do desenvolvedor são encorajadoras: "por um longo tempo, porque o BeOS não era compatível com POSIX", mas o Haiku "na maior parte" já é assim.
Portando um Aplicativo CLI Simples
O primeiro pensamento foi portar o aplicativo avrdude , mas, como se viu, já havia sido feito há muito tempo.
Primeira tentativa: nada para assistir
O que não consigo entender é que, por mais de 10 anos, os aplicativos foram portados para o Haiku - apesar do fato de o próprio sistema operacional nem sequer ter a versão 1.0.
Segunda tentativa: precisa reescrever
Portanto, usarei a ptouch-770 , CLI para controlar a impressora Brother P-Touch 770, na qual imprimo etiquetas.
Imprimo várias etiquetas e você já deve ter visto isso em um artigo anterior. Anteriormente, escrevi um pequeno programa wrapper com uma GUI em Python (já que está no Gtk +, terei que reescrevê-lo, o que é um bom motivo para aprender alguma coisa).
Impressora de etiquetas Brother P-Touch 770. Funciona com o Haiku?
O gerenciador de pacotes do Haiku conhece bibliotecas e comandos; portanto, se eu receber a mensagem “não é possível encontrar o libintl” ao executar o configure , eu apenas pkgman install devel:libintl e o pacote necessário será encontrado. Semelhante ao pkgman install cmd:rsync . Bem, etc.
Exceto quando isso não funcionar:
/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
Talvez o udev esteja muito cheio, por isso não existe para o Haiku. O que significa a necessidade de editar o código fonte que estou tentando compilar.
Você não vai pular acima da cabeça e nem sei por onde começar.
Terceira tentativa
Seria bom ter o tmate para o Haiku, então eu deixaria os desenvolvedores do Haiku se conectarem à minha sessão do terminal - no caso de algo dar errado. As instruções são bastante simples:
./autogen.sh ./configure make make install
Parece bom, então por que não experimentá-lo no 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
Nesta etapa, abro o HaikuDepot e procuro curses .
Algo foi encontrado, o que me deu uma dica para uma solicitação mais competente:
/Haiku/home/tmate> pkgman install devel:libncurses (...) 100% ncurses6_devel-6.1-1-x86_64.hpkg [835.62 KiB] (...)./configure (...) checking for msgpack >= 1.1.0... no configure: error: "msgpack >= 1.1.0 not found"/Haiku/home/tmate> pkgman install devel:msgpack (...) *** Failed to find a match for "devel:msgpack": Name not found/Haiku/home/tmate> pkgman install devel:libmsgpack (...) *** Failed to find a match for "devel:libmsgpack": Name not found
Novamente foi para o HaikuDepot e, é claro, encontrou o devel:msgpack_c_cpp_devel . Que tipo de nomes estranhos?
/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
Nesta etapa, percebi que a portabilidade de um programa para o Haiku requer muito mais conhecimento do que você precisa para uma simples reconstrução.
Conversei com os desenvolvedores amigáveis do Haiku, verificou-se que há um erro no msgpack e, após alguns minutos, vejo um patch no HaikuPorts. Eu pessoalmente observo como um pacote fixo é construído aqui (buildslave - máquinas virtuais).
Construir um msgpack fixo no buildmaster
Enquanto isso, envie o patch para o upstream para adicionar o suporte do Haiku ao msgpack .
Cinco minutos depois, o msgpack atualizado já está disponível no Haiku:
/Haiku/home/tmate> pkgman update (...) The following changes will be made: in system: upgrade package msgpack_c_cpp-3.1.1-1 to 3.2.0-2 from repository HaikuPorts upgrade package msgpack_c_cpp_devel-3.1.1-1 to 3.2.0-2 from repository HaikuPorts Continue? [yes/no] (yes) : y 100% msgpack_c_cpp-3.2.0-2-x86_64.hpkg [13.43 KiB] (...) [system] Done.
Inesperadamente bom. Eu disse isso ?!
Voltando à tarefa original:
/Haiku/home/tmate> make (...) In file included from tmux.h:40, from tty.c:32: compat.h:266: warning: "AT_FDCWD" redefined #define AT_FDCWD -100 In file included from tty.c:25: /boot/system/develop/headers/posix/fcntl.h:62: note: this is the location of the previous definition #define AT_FDCWD (-1) /* CWD FD for the *at() functions */ tty.c: In function 'tty_init_termios': tty.c:278:48: error: 'IMAXBEL' undeclared (first use in this function); did you mean 'MAXLABEL'? tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|IMAXBEL|ISTRIP); ^~~~~~~ MAXLABEL tty.c:278:48: note: each undeclared identifier is reported only once for each function it appears in Makefile:969: recipe for target 'tty.o' failed make: *** [tty.o] Error 1
Agora parece que o msgpack não é culpado. Comentando IMAXLABEL em tty.c assim:
tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|/*IMAXBEL|*/ISTRIP);
Resultado:
osdep-unknown.c: In function 'osdep_get_cwd': osdep-unknown.c:32:19: warning: unused parameter 'fd' [-Wunused-parameter] osdep_get_cwd(int fd) ~~~~^~ make: *** No rule to make target 'compat/forkpty-unknown.c', needed by 'compat/forkpty-unknown.o'. Stop.
Bem, novamente ... A propósito:
/Haiku/home/tmate> ./configure | grep -i OPENAT checking for openat... no
Sr. O waddlesplash diz onde cavar:
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd" (...)/Haiku/home/tmate> make (...) In file included from tmux.h:40, from window.c:31: compat.h:266: warning: "AT_FDCWD" redefined #define AT_FDCWD -100 In file included from window.c:22: /boot/system/develop/headers/posix/fcntl.h:62: note: this is the location of the previous definition #define AT_FDCWD (-1) /* CWD FD for the *at() functions */ make: *** No rule to make target 'compat/forkpty-unknown.c', needed by 'compat/forkpty-unknown.o'. Stop.
Aqui eu expus o config.log .
Eles me explicaram que há algo mais na libnetwork no libresolv no Haiku. Provavelmente é necessário editar mais o código. Eu tenho que pensar ...
find . -type f -exec sed -i -e 's|lresolv|lnetwork|g' {} \;
A eterna pergunta: o que está acontecendo.
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd" (...)/Haiku/home/tmate> make (...) # Success!# Let's run it:/Haiku/home/tmate> ./tmate runtime_loader: /boot/system/lib/libssh.so.4.7.2: Could not resolve symbol '__stack_chk_guard' resolve symbol "__stack_chk_guard" returned: -2147478780 runtime_loader: /boot/system/lib/libssh.so.4.7.2: Troubles relocating: Symbol not found
O mesmo, apenas no perfil. Pesquisei no Google e encontrei . Se adicionar -lssp "às vezes" ajudar, eu tento:
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp" (...)/Haiku/home/tmate> make (...)/Haiku/home/tmate> ./tmate
Uau! Está começando! Mas ...
[tmate] ssh.tmate.io lookup failure. Retrying in 2 seconds (non-recoverable failure in name resolution)
Vou tentar depurar o arquivo aqui :
/Haiku/home/tmate> strace -f ./tmate >log 2>&1
"Bad port ID" já é como um cartão de visita haiku . Talvez alguém imagine o que está errado e como corrigi-lo? Se alguma coisa, vou atualizar o artigo. Link para o GitHub .
Portando um aplicativo GUI para Qt.
Eu escolho um aplicativo QML simples.
/> 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 simples. Menos de um minuto!
Empacotando aplicativos no hpkg usando o haikuporter e o haikuports.
Por onde começar? Não há documentação simples, vou ao canal #haiku em irc.freenode.net e ouço:
- O comando
package é uma maneira de baixo nível de criar pacotes. Na maioria das vezes, PackageInfo é suficiente, conforme descrito na seção "Transformando-o em um pacote .hpkg adequado" - Eu preciso fazer algo assim
- Você pode usar o hpkg-creator (falha, relatório de erros )
Não está claro o que fazer. Suponho que preciso de um guia para iniciantes no estilo de "Hello World!", Idealmente um vídeo. Seria bom ter uma introdução conveniente ao HaikuPorter, como foi feito no GNU hello.
Eu li o seguinte:
haikuporter é uma ferramenta para criar projetos em lote compartilhados para o Haiku. Ele usa o repositório HaikuPorts como base para todos os pacotes. Para criar pacotes, são utilizadas receitas do haikuporter.
Além disso, descubro que:
Não há necessidade de manter receitas no cofre do HaikuPorts. Você pode criar outro repositório, colocar receitas nele e apontar o haikuporter para ele.
Exatamente o que eu preciso - se você não procurar uma maneira de publicar o pacote publicamente. Mas este é um tópico para outro post.
Instalar haikuporter e haikuports
cd /boot/home/ git clone https://github.com/haikuports/haikuporter --depth=50 git clone https://github.com/haikuports/haikuports --depth=50 ln -s /boot/home/haikuporter/haikuporter /boot/home/config/non-packaged/bin/ # make it runnable from anywhere cd haikuporter cp haikuports-sample.conf /boot/home/config/settings/haikuports.conf sed -i -e 's|/mydisk/haikuports|/boot/home/haikuports|g' /boot/home/config/settings/haikuports.conf
Escrevendo uma receita
SUMMARY="Demo QtQuick application" DESCRIPTION="QtQuickApp is a demo QtQuick application for testing Haiku porting and packaging" HOMEPAGE="https://github.com/probonopd/QtQuickApp" COPYRIGHT="None" LICENSE="MIT" REVISION="1" SOURCE_URI="https://github.com/probonopd/QtQuickApp.git" #PATCHES="" ARCHITECTURES="x86_64" PROVIDES=" QtQuickApp = $portVersion " REQUIRES=" haiku " BUILD_REQUIRES=" haiku_devel cmd:qmake "BUILD() { qmake . make $jobArgs }INSTALL() { make install }
Conjunto da receita
QtQuickApp-1.0.recipe arquivo como QtQuickApp-1.0.recipe e, em seguida, execute o aikuporter -S ./QuickApp-1.0.recipe . As dependências são verificadas para todos os pacotes no repositório haikuports , o que leva algum tempo. Eu vou tomar um café.
E por que essa verificação deve ser feita na minha máquina local e não centralmente no servidor uma vez para todos?
De acordo com o sr. waddlesplash:
Dessa forma, você pode reescrever qualquer arquivo no repositório;) Você pode otimizar isso ligeiramente calculando as informações necessárias quando necessário, porque as alterações mais recentes são bastante raras.
~/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
Acontece que não há um arquivo de receita comum que contenha o código fonte do seu aplicativo. Você precisa mantê-lo no repositório no formato HaikuPorts.
~/QtQuickApp> mv QtQuickApp-1.0.recipe ../haikuports/app-misc/QtQuickApp/ ~/QtQuickApp> ../haikuport ~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe
Esse fato torna a montagem mais complicada. Eu realmente não gosto, mas acho que é necessário que, no final, todo o software de código aberto apareça no HaikuPorts.
Eu recebo o seguinte:
~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe Checking if any dependency-infos need to be updated ... updating dependency infos of QtQuickApp-1.0 Looking for stale dependency-infos ... Error: QtQuickApp-1.0.recipe not found in tree.
O que está errado? Depois de ler o irc, eu faço:
~/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!
Uma questão interessante surgiu. Se eu adicionar uma soma de verificação à receita - ela corresponderá ao último git commit para integração contínua? (O desenvolvedor confirma: "Nada vai acontecer. As receitas são projetadas para serem relativamente estáveis.")
Por diversão, adicione à receita:
CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"
Ainda não está feliz:
~/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
O que ele esta fazendo? Afinal, este é o repositório git, o código já está lá diretamente, não há nada para descompactar. Do meu ponto de vista, a ferramenta deve ser inteligente o suficiente para não procurar o desempacotador se estiver acima da URL com o GitHub.
Talvez uri git: // funcione
SOURCE_URI="git://github.com/probonopd/QtQuickApp.git"
Agora ele reclama assim:
Downloading: git://github.com/probonopd/QtQuickApp.git ... Error: Downloading from unsafe sources is disabled in haikuports.conf!
Hmm, e por que tudo é tão complicado, por que você não pode simplesmente "trabalhar"? No final, não é tão raro criar algo com o GitHub. As ferramentas funcionam imediatamente, sem a necessidade de personalização, ou como eu chamo de "confusão".
Talvez funcione assim:
SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"
Não. Ainda recebendo esse erro estúpido e fazendo como descrito aqui
sed -i -e 's|#ALLOW_UNSAFE_SOURCES|ALLOW_UNSAFE_SOURCES|g' /boot/home/config/settings/haikuports.conf
Estou indo um pouco mais longe, mas por que ele está gritando comigo (o GitHub não é seguro!) E ainda está tentando descompactar alguma coisa.
De acordo com o sr. waddlesplash :
Bem, sim, o motivo foi o desejo de verificar a integridade dos dados obtidos para a montagem. Uma opção é verificar a soma de verificação do arquivo morto, mas é claro que você também pode fazer o hash de arquivos individuais, que não serão implementados, porque leva muito mais tempo. A conseqüência disso é a "insegurança" do git e de outros VCS. Provavelmente, esse sempre será o caso, pois a criação de um arquivo no GitHub é bastante fácil e geralmente mais rápida. Bem, no futuro, talvez a mensagem de erro não seja tão chamativa ... (não mesclamos mais essas receitas no 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
Como um hábito antigo, vou pedir boas pessoas no canal #haiku na rede irc.freenode.net. E onde estou sem eles? Após o prompt, percebi que deveria usar:
srcGitRev="d0769f53639eaffdcd070bddfb7113c04f2a0de8" SOURCE_URI="https://github.com/probonopd/QtQuickApp/archive/$srcGitRev.tar.gz" SOURCE_DIR="QtQuickApp-$srcGitRev" CHECKSUM_SHA256="db8ab861cfec0ca201e9c7b6c0c9e5e828cb4e9e69d98e3714ce0369ba9d9522"
Bem, ficou claro o que estava fazendo - estava baixando o arquivo com as fontes de uma certa revisão. É estúpido, do meu ponto de vista, e não exatamente o que eu queria, ou seja, baixar a última revisão do ramo principal.
Um dos desenvolvedores explicou da seguinte maneira:
Como temos nosso próprio IC, tudo o que é colocado no repositório haikuports será protegido por todos os usuários, e não queremos arriscar coletar e entregar "toda a versão mais recente para upstream".
Entendi! De qualquer forma, isso aconteceu:
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 (...)
Repete esse ad infinitum. Aparentemente, isso é um erro (existe um aplicativo? Eu não encontrei).
Com o haikuporter e o repositório do haikuports, você não sente que o nível "simplesmente funciona", mas como desenvolvedor, gosto de algumas coisas sobre como trabalhar com o Haiku. Na maioria das vezes, isso é semelhante ao Open Build Service - um conjunto de ferramentas para criar assemblies Linux: extremamente poderoso, com uma abordagem sistemática, mas supérfluo para meu pequeno aplicativo hello world.
Mais uma vez, de acordo com o sr. waddlesplash:
De fato, o HaikuPorter é muito rigoroso por padrão (além disso, existe o modo lint e o modo estrito, tornando-o ainda mais rigoroso!), Mas apenas porque ele cria pacotes que funcionarão, e não apenas cria pacotes. Portanto, ele jura dependências não declaradas, bibliotecas não importadas corretamente, versões incorretas etc. O objetivo é capturar todos os problemas sem exceção, incluindo os futuros, antes que o usuário descubra isso (portanto, não foi possível instalar o avrdude, porque a dependência foi realmente indicada na receita). Bibliotecas não são apenas pacotes separados ou mesmo versões indefinidas do SO. O HaikuPorter garante que tudo isso seja seguido nas receitas para evitar erros de tempo de execução.
Em princípio, esse nível de rigor é justificado ao criar o sistema operacional, mas me parece desnecessário para o aplicativo hello world. Eu decidi tentar outra coisa.
Talvez esta instrução simples sirva melhor para mim?
mkdir -p apps/ cp QtQuickApp apps/cat > .PackageInfo <<\EOF name QtQuickApp version 1.0-1 architecture x86_64 summary "Demo QtQuick application" description "QtQuickApp is a demo QtQuick application for testing Haiku porting and packaging" packager "probono" vendor "probono" copyrights "probono" licenses "MIT" provides { QtQuickApp = 1.0-1 }requires { qt5 } EOFpackage create -b QtQuickApp.hpkg package add QtQuickApp.hpkg apps# See below if you also want the application # to appear in the menu
Inesperadamente rápido, inesperadamente simples, inesperadamente eficaz. Do jeito que eu gosto, incrível!
Instalação - o que e onde?
Movido o arquivo QtQuickApp.hpkg para ~/config/packages usando o gerenciador de arquivos, após o qual o QtQuickApp apareceu magicamente em ~/config/apps .
Mais uma vez, inesperadamente rápido, simples e eficaz. Incrível, incrível!
Mas ... (onde sem eles!)
O aplicativo ainda não está na lista de menus do aplicativo e no QuickLaunch. Eu acho que já sei como consertar. No gerenciador de arquivos, movo o QtQuickApp.hpkg de ~ / config / packages para / system / packages.
Nah, ainda falta. Aparentemente, eu (bem, a instrução) perdi alguma coisa.
Tendo examinado a guia "Conteúdo" no HaikuDepot para outras aplicações, vi que existem arquivos como /data/mimedb/application/x-vnd... que é ainda mais notável, /data/deskbar/menu/Applications/…
Bem, e o que devo colocar lá? Bem ...
mkdir -p data/deskbar/menu/Applications/ ( cd data/deskbar/menu/Applications ; ln -s ../../../../apps/QtQuickApp . ) package add QtQuickApp.hpkg apps data
Tenho certeza de que esse truque dará uma carona, mas ainda restam perguntas: por que é necessário, para que serve? Na minha opinião, isso destrói a impressão geral de que o sistema é tão sofisticado.
Como explicado pelo sr. waddlesplash:
Às vezes, existem aplicativos que outros aplicativos precisam, mas não no menu. Por exemplo, o LegacyPackageInstaller na sua captura de tela que processa arquivos .pkg no formato BeOS. Eu quero que os usuários os definam, mas sua presença no menu levará à confusão.
Por alguma razão, parece-me que existe uma solução mais simples, por exemplo, Hidden=true nos arquivos .desktop Linux. Por que não tornar as informações "ocultas" um recurso e um atributo do sistema de arquivos?
O que não é particularmente sofisticado é o nome do (certo) aplicativo que exibe o menu, a deskbar , está fortemente ligado ao longo do caminho.
Sr. O waddlesplash nesta ocasião explica:
"Barra de mesa" nesse caso deve ser entendida como um tipo de termo geral (aproximadamente o mesmo que "barra de tarefas", referindo-se ao aplicativo Windows e ao conceito geral). Bem, como essa é uma deskbar , não uma " deskbar ", isso pode ser entendido de maneira semelhante.
2 diretórios "quase idênticos" com aplicativos neles
Por que existem 2 diretórios com aplicativos e também por que existe um no meu QtQuickApplication e não no outro? (Afinal, este não é um sistema, mas o segundo usuário, que eu pessoalmente entenderia).
Estou realmente confuso e acho que devemos unificar isso.
Comente mr. waddlesplash
No diretório de aplicativos, existem aplicativos que não são necessários no menu. Mas a situação do menu realmente precisa ser melhorada, para torná-lo mais personalizável.
Aplicação, ou isso não vai acontecer;)
Pensei: é realmente necessário colocar aplicativos em /system/apps , se os usuários os virem lá - é indesejável. Talvez seja melhor colocá-los em outro lugar onde o usuário não os encontre? Assim como no Mac OS X, onde o conteúdo dos pacotes .app , que não devem ser visíveis ao usuário em /Applications , estão ocultos nas entranhas de / System / Library / ... ``.
E as dependências?
Eu acho que vale a pena apontar dependências de alguma forma, certo? O Qt pode ser considerado uma parte obrigatória da instalação padrão do Haiku? Nope! Qt não está instalado por padrão. Um programa de compilação de pacotes pode detectar automaticamente dependências verificando arquivos ELF? Foi-me dito que o HaikuPorter realmente funciona, mas o package não. Isso porque ele é apenas um " hpkg pacotes", que por si só simplesmente cria arquivos hpkg .
O Haiku deve ser mais refinado adicionando uma política segundo a qual um pacote não deve ter dependências de pacotes não incluídos no haikuports ? (Eu gostaria muito, pois essa política facilita muito a tarefa - o sistema seria capaz de resolver automaticamente as dependências de cada pacote baixado de qualquer lugar sem se preocupar com fontes de pacotes adicionais).
Sr. waddlesplash explica:
, , ( ) — .
-, haikuports, . , , . [ AppImage? — . tradutor]
? , , .
?
, 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 — .
Conclusão
POSIX Haiku , , . , #haiku irc.freenode.net. , .
, Qt, — . .
, " ", .. , haikuports. ( ) GitHub . Haiku Linux, Mc, "" XCode .app , .dmg , .
"" , , Linux, , , Haiku , .
Tente você mesmo! Afinal, o projeto Haiku fornece imagens diárias de download de DVD ou USB. Para instalar, basta baixar a imagem e gravá-la em uma unidade flash USB usando o Etcher
Tem uma pergunta? Convidamos você para o canal de telegrama em russo.
Visão geral do bug: Como dar um tiro no pé em C e C ++. Coleção de receitas do sistema operacional Haiku
: Haiku.
: