TL;DR: O novato viu Haiku pela primeira vez e tenta portar alguns programas do mundo Linux.
Meu primeiro programa portado para Haiku, empacotado no formato hpkg.
descobri o Haiku, um sistema operacional surpreendentemente bom para PCs.
Hoje vou aprender a portar novos programas para este sistema operacional. O foco principal é descrever a primeira experiência de transição para o Haiku do ponto de vista de um desenvolvedor Linux. Peço desculpas pelos erros bobos que cometi durante o processo, já que não se passou nem uma semana desde que fiz o download do Haiku pela primeira vez.
Quero atingir três objetivos:
- Portar um aplicativo CLI simples.
- Portar um aplicativo com GUI em Qt.
- Depois, empacotar tudo no formato hpkg (já que ainda estou pensando em adaptar AppDir e AppImage para Haiku…)
Vamos começar. Na seção e , bem como em de HaikuPorts encontrei a direção certa. Há até um livro online em PDF. .
467 páginas — e isso desde 1997! Olhar por dentro é assustador, mas espero o melhor. As palavras do desenvolvedor são encorajadoras: 'é longo, pois o BeOS não era POSIX compatível', mas o Haiku 'na maior parte' já é.
Portando um aplicativo CLI simples.
A primeira ideia foi portar o aplicativo , mas, como se viu, já há muito tempo.
Primeira tentativa: nada para ver.
O que eu não consigo entender é que já — embora o próprio sistema operacional ainda não tenha versão 1.0.
Segunda tentativa: preciso reescrever.
Então, vou usar , CLI para gerenciar a impressora Brother P-Touch 770, na qual imprimo etiquetas.
Imprimo vários tipos de etiquetas nele, e você talvez já o tenha visto no artigo anterior. Um pouco antes, escrevi um pequeno programa de wrapper com GUI em Python (como está em Gtk+ — terei que reescrever, e essa é uma boa oportunidade para aprender).
Impressora de etiquetas Brother P-Touch 770. Funcionará no Haiku?
O gerenciador de pacotes do Haiku conhece bibliotecas e comandos, então, se eu receber a mensagem 'não consegue encontrar libintl' ao executar configure — eu simplesmente executo pkgman install devel:libintl e o pacote necessário será encontrado. Da mesma forma, pkgman install cmd:rsync.Bem, e assim por diante.
Exceto nas ocasiões em que isso não funciona:
/Haiku/home> git clone https://github.com/probonopd/ptouch-770
Cloning into 'ptouch-770'...
remote: Enumerating objects: 134, done.
remote: Total 134 (delta 0), reused 0 (delta 0), pack-reused 134
Receiving objects: 100% (134/134), 98.91 KiB | 637.00 KiB/s, done.
Resolving deltas: 100% (71/71), done./Haiku/home> cd ptouch-770//Haiku/home/ptouch-770> make
gcc -Wall -O2 -c -o ptouch-770-write.o ptouch-770-write.c
ptouch-770-write.c:28:10: fatal error: libudev.h: No such file or directory
#include <libudev.h>
^~~~~~~~~~~
compilation terminated.
Makefile:16: recipe for target 'ptouch-770-write.o' failed
make: *** [ptouch-770-write.o] Error 1/Haiku/home/ptouch-770> pkgman install devel:libudev
100% repochecksum-1 [65 bytes]
Validating checksum for Haiku...done.
100% repochecksum-1 [64 bytes]
Validating checksum for HaikuPorts...done.
*** Failed to find a match for "devel:libudev": Name not found/Haiku/home/ptouch-770> pkgman install devel:udev
100% repochecksum-1 [65 bytes]
Validating checksum for Haiku...done.
100% repochecksum-1 [64 bytes]
Validating checksum for HaikuPorts...done.
*** Failed to find a match for "devel:udev": Name not foundTalvez o udev seja muito linuxiano, por isso não existe para o Haiku. O que significa que é necessário modificar o código-fonte que estou tentando compilar.
Ah, não dá para superar os limites, e eu não sei nem por onde começar.
Terceira tentativa
Seria bom ter tmate para o Haiku, então eu permitiria que os desenvolvedores do Haiku se conectassem à minha sessão de terminal — caso algo desse errado. As instruções são bastante simples:
./autogen.sh
./configure
make
make installParece bom, então por que não tentar isso 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 foundNeste passo, eu abro o HaikuDepot e procuro por curses.
Achei algo que me deu uma dica para uma busca mais informada:
/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 foundVoltei ao HaikuDepot e, claro, encontrei devel:msgpack_c_cpp_devel. Que 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 1Neste passo, percebi que portar o programa para o Haiku exige muito mais conhecimento do que apenas uma recompilação simples.
Conversei com os desenvolvedores amigáveis do Haiku, e descobri que há um erro no msgpack, e depois de alguns minutos vejo um patch no HaikuPorts. Observei em primeira mão como o pacote corrigido (buildslave — máquinas virtuais).
Construindo o msgpack corrigido no buildmaster
Enquanto isso, envio um patch para o upstream .
Cinco minutos depois, a versão atualizada do msgpack 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?!
Volto à 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 1Atualmente, parece que o msgpack não é o culpado. Comento 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.Então, aqui vamos nós de novo... Aliás:
/Haiku/home/tmate> ./configure | grep -i OPENAT
checking for openat... nodá uma dica de onde procurar:
/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 postei .
Me explicaram que há algo a mais no libresolv no Haiku em libnetwork. Parece que preciso continuar ajustando o código. Preciso 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 foundO mesmo, só que mais profundo. Pesquisei e . Se adicionar -lssp "às vezes" ajuda, estou tentando:
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp"
(...)/Haiku/home/tmate> make
(...)/Haiku/home/tmate> ./tmateUau! Está rodando! Mas...
[tmate] falha na busca por ssh.tmate.io. Tentando novamente em 2 segundos (falha irreparável na resolução de nome)Vou tentar depurar, :
/Haiku/home/tmate> strace -f ./tmate >log 2>&1"Bad port ID" — isso já é como um cartão de visita Talvez alguém saiba o que está errado e como corrigir? Se necessário, vou atualizar o artigo. Link para .
Portando aplicações GUI para Qt.
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 em hpkg usando haikuporter e haikuports.
Por onde começar? Não há documentação simples, vou para o canal #haiku na irc.freenode.net e ouço:
- Time
pacote— uma forma de baixo nível de criar pacotes. Na maior parte, é suficiente usar PackageInfo, como descrito na seção 'Transformando em um pacote .hpkg adequado' - Preciso fazer algo
- Pode-se usar (ele está travando, )
Não está claro o que fazer. Acho que preciso de um guia para iniciantes no estilo 'Olá, Mundo!', de preferência em vídeo. Também seria bom ter uma introdução prática ao HaikuPorter, como feita no GNU hello.
Estou lendo o seguinte:
haikuporteré uma ferramenta para criar projetos de pacotes genéricos para o Haiku. Ela usa o repositório HaikuPorts como base para todos os pacotes. Para criar pacotes, utiliza receitas do haikuporter.
Além disso, descubro que:
Não é necessário manter as receitas no armazenamento do HaikuPorts. Pode-se criar outro repositório, colocar as receitas lá e, em seguida, apontar o haikuporter para ele.
É exatamente o que eu preciso — a menos que eu esteja procurando uma forma de publicar o pacote. Mas isso é assunto para outro post.
Instalação do 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/ # torna executável de qualquer lugar
cd haikuporter
cp haikuports-sample.conf /boot/home/config/settings/haikuports.conf
sed -i -e 's|/mydisk/haikuports|/boot/home/haikuports|g' /boot/home/config/settings/haikuports.confEscrevendo a receita
SUMMARY="Demo de aplicação QtQuick"
DESCRIPTION="QtQuickApp é uma demonstração de aplicação QtQuick para testes de portabilidade e empacotamento no Haiku"
HOMEPAGE="https://github.com/probonopd/QtQuickApp"
COPYRIGHT="Nenhum"
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
}Compilando a receita
Salvando o arquivo como QtQuickApp-1.0.recipe, em seguida, executando haikuporter -S ./QuickApp-1.0.recipe. Verificando dependências para todos os pacotes no repositório , o que leva algum tempo. Vou tomar um café.
E por que essa verificação deve ser feita na minha máquina local, e não centralizadamente em um servidor uma vez para todos?
De acordo com o sr. waddlesplash:
Com a possibilidade de reescrever qualquer arquivo no repositório 😉 Pode-se otimizar isso um pouco, calculando as informações necessárias quando preciso, pois as últimas alterações são bastante raras.
~/QtQuickApp> haikuporter QtQuickApp-1.0.recipe
Verificando se alguma informação de dependência precisa ser atualizada ...
Buscando informações de dependência desatualizadas ...
Erro: QtQuickApp não encontrado no repositórioParece que não existe um arquivo de receita comum que contenha o código fonte do seu aplicativo. É necessário mantê-lo em um repositório no formato HaikuPorts.
~\/QtQuickApp> mv QtQuickApp-1.0.recipe ..\/haikuports\/app-misc\/QtQuickApp\/\n~\/QtQuickApp> ..\/haikuport\n~\/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipeEsse fato torna a construção mais complicada. Não gosto muito disso, mas acho que é necessário para que, no final, todo o software de código aberto apareça no HaikuPorts.
Recebo o seguinte:
~\/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe\nVerificando se alguma informação de dependência precisa ser atualizada ...\n atualizando informações de dependência do QtQuickApp-1.0\nProcurando informações de dependência desatualizadas ...\nErro: QtQuickApp-1.0.recipe não encontrado na árvore.O que está errado? Depois de ler o irc, faço:
~\/QtQuickApp> haikuporter -S QtQuickApp\nVerificando se alguma informação de dependência precisa ser atualizada ...\n atualizando informações de dependência do QtQuickApp-1.0\nProcurando informações de dependência desatualizadas ...\n----------------------------------------------------------------------\napp-misc::QtQuickApp-1.0\n \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe\n----------------------------------------------------------------------Baixando: https:\/\/github.com\/probonopd\/QtQuickApp.git ...\n--2019-07-14 16:12:44-- https:\/\/github.com\/probonopd\/QtQuickApp.git\nResolvendo github.com... 140.82.118.3\nConectando ao github.com|140.82.118.3|:443... conectado.\nRequisição HTTP enviada, aguardando resposta... 301 Moved Permanently\nLocalização: https:\/\/github.com\/probonopd\/QtQuickApp [seguindo]\n--2019-07-14 16:12:45-- https:\/\/github.com\/probonopd\/QtQuickApp\nReutilizando a conexão existente com github.com:443.\nRequisição HTTP enviada, aguardando resposta... 200 OK\nTamanho: indefinido [text\/html]\nSalvando em: ‘\/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git’\n 0K . 1.34M=0.06s\n2019-07-14 16:12:45 (1.34 MB\/s) - ‘\/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git’ salvo [90094]\nValidando checksum de QtQuickApp.git\nAviso: ----- CHECKSUM TEMPLATE -----\nAviso: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"\nAviso: -----------------------------\nErro: Nenhum checksum encontrado na receita!Surge uma pergunta interessante. Se eu adicionar um checksum à receita — ele corresponderá ao último commit do git para integração contínua? (O desenvolvedor confirma: "Nada vai funcionar. As receitas são projetadas para serem relativamente estáveis").
Por diversão, eles adicionam à receita:
CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"Ainda não está bom:
~\/QtQuickApp> haikuporter -S QtQuickApp\nVerificando se alguma informação de dependência precisa ser atualizada ...\n atualizando informações de dependência do QtQuickApp-1.0\nProcurando informações de dependência desatualizadas ...\n----------------------------------------------------------------------\napp-misc::QtQuickApp-1.0\n \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe\n----------------------------------------------------------------------\nIgnorando download da fonte para QtQuickApp.git\nValidando checksum de QtQuickApp.git\nDescompactando a fonte de QtQuickApp.git\nErro: Tipo de arquivo de archive não reconhecido no arquivo \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.gitO que está acontecendo? Afinal, este é um repositório git, o código já está lá diretamente, não há nada a descompactar. Na minha opinião, a ferramenta deve ser inteligente o suficiente para não procurar um descompactador se tiver um URL do GitHub.
Talvez funcione com uri git://
SOURCE_URI="git://github.com/probonopd/QtQuickApp.git"Agora ele está reclamando assim:
Baixando: git://github.com/probonopd/QtQuickApp.git ...
Erro: Baixar de fontes não seguras está desativado no haikuports.conf!Hum, e por que tudo é tão complicado? Por que não pode "simplesmente funcionar"? Afinal, não é tão raro conseguir compilar algo do GitHub. Estou falando de ferramentas que funcionam imediatamente, sem necessidade de configuração, ou como eu chamo "trabalho desnecessário".
Talvez funcione assim:
SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"Não. Ainda estou recebendo esse erro esquisito e fazendo,
sed -i -e 's|#ALLOW_UNSAFE_SOURCES|ALLOW_UNSAFE_SOURCES|g' /boot/home/config/settings/haikuports.confEstou avançando um pouco mais, mas por que ele está gritando comigo (o GitHub não é seguro!) e ainda está tentando descompactar algo.
De acordo com :
Sim, a razão foi a vontade de verificar a integridade dos dados recebidos para a compilação. Uma opção é verificar a soma de verificação do arquivo, mas também se pode fazer hashing de arquivos individuais, o que não será implementado, pois isso leva muito mais tempo. Isso é o que causa a "insegurança" do git e de outros VCS. Provavelmente isso sempre será assim, já que criar um arquivo no GitHub é bastante fácil e frequentemente mais rápido. E no futuro, talvez a mensagem de erro não seja tão alarmante… (não estamos mais fundindo esses tipos de receitas no HaikuPorts).
~ /QtQuickApp> haikuporter -S QtQuickApp
Verificando se alguma informação de dependência precisa ser atualizada ...
Procurando informações de dependência obsoletas ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
/boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Baixando: git+https://github.com/probonopd/QtQuickApp.git ...
Atenção: FONTES NÃO SEGURAS SÃO RUINS E NÃO DEVEM SER USADAS EM PRODUÇÃO
Atenção: POR FAVOR, MUDE PARA UM DOWNLOAD DE ARQUIVO ESTÁTICO COM CHECKSUM O MAIS RÁPIDO POSSÍVEL!
Clonando para repositório bare '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
Descompactando a fonte de QtQuickApp.git
tar: /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0: Não é possível abrir: Não existe esse arquivo ou diretório
tar: O erro não é recuperável: saindo agora
O comando 'git archive HEAD | tar -x -C "/boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0"' retornou o status de saída diferente de zero 2Por hábito, vou perguntar a pessoas bondosas no canal #haiku na rede irc.freenode.net. E onde eu estaria sem eles? Após a dica, percebi que precisava usar:
srcGitRev="d0769f53639eaffdcd070bddfb7113c04f2a0de8"
SOURCE_URI="https://github.com/probonopd/QtQuickApp/archive/$srcGitRev.tar.gz"
SOURCE_DIR="QtQuickApp-$srcGitRev"
CHECKSUM_SHA256="db8ab861cfec0ca201e9c7b6c0c9e5e828cb4e9e69d98e3714ce0369ba9d9522"Entendi o que isso faz — baixa um arquivo zip com os arquivos de origem de uma determinada revisão. Parece uma abordagem estranha, na minha opinião, e não é exatamente o que eu queria, que era baixar a última revisão da branch master.
Um dos desenvolvedores explicou da seguinte forma:
Temos nosso próprio CI, então tudo o que estiver no repositório haikuports será empacotado para todos os usuários, e não queremos correr o risco de compilar e fornecer 'tudo na última versão do upstream'.
Entendi! De qualquer forma, o resultado foi esse:
aguardando a ativação do pacote de build QtQuickApp-1.0-1
aguardando a ativação do pacote de build QtQuickApp-1.0-1
aguardando a ativação do pacote de build QtQuickApp-1.0-1
aguardando a ativação do pacote de build QtQuickApp-1.0-1
aguardando a ativação do pacote de build QtQuickApp-1.0-1
(...)Ele repete isso infinitamente. Aparentemente, isso é um erro (existe um pedido? Não encontrei).
Com haikuporter e repositório Não sinto que há um nível de 'simplesmente funciona', mas, como desenvolvedor, algumas coisas no trabalho com Haiku me agradam. Na maior parte, parece com o Open Build Service — um conjunto de ferramentas para construir pacotes Linux: extremamente poderoso, com uma abordagem sistemática, mas excessivo para meu pequeno aplicativo do tipo 'hello world'.
Novamente, de acordo com o sr. waddlesplash:
De fato, o HaikuPorter é bastante rigoroso por padrão (além de ter um modo lint e um modo rigoroso que o tornam ainda mais estrito!), mas isso acontece porque ele cria pacotes que funcionarão, e não apenas cria pacotes. Portanto, ele reclama sobre dependências não declaradas, bibliotecas não importadas corretamente, versões incorretas, etc. O objetivo é capturar todos os problemas, incluindo os futuros, antes que o usuário perceba (é por isso que não foi possível instalar o avrdude, pois havia uma dependência declarada na receita). Bibliotecas não são apenas pacotes separados e nem mesmo versões específicas de SO. O HaikuPorter acompanha a conformidade de tudo isso nas próprias receitas para evitar erros em tempo de execução.
De certa forma, esse nível de rigor é justificável ao criar um sistema operacional, mas me parece excessivo para um aplicativo 'hello world'. Decidi tentar algo diferente.
Empacotando aplicativos no formato hpkg, usando o comando 'package create'
Talvez, uma instrução simples me sirva melhor?
mkdir -p apps/
cp QtQuickApp apps/cat > .PackageInfo <<EOF
name QtQuickApp
version 1.0-1
architecture x86_64
summary "Aplicativo de demonstração QtQuick"
description "QtQuickApp é um aplicativo de demonstração QtQuick para testar a portabilidade e empacotamento do Haiku"
packager "probono"
vendor "probono"
copyrights "probono"
licenses "MIT"
provides {
QtQuickApp = 1.0-1
}requires {
qt5
}
EOFpackage create -b QtQuickApp.hpkg
package add QtQuickApp.hpkg apps# Veja abaixo se você também quer que o aplicativo
# apareça no menuSurpreendentemente rápido, surpreendentemente simples, surpreendentemente eficaz. Exatamente como gosto, impressionante!
Instalação — o que e onde?
Mudei o arquivo QtQuickApp.hpkg para ~config/packages, usando o gerenciador de arquivos, depois disso o QtQuickApp apareceu magicamente em ~config/apps.
Novamente surpreendentemente rápido, simples e eficaz. Impressionante, inacreditável!
Mas… (como poderia ser diferente!)
O aplicativo ainda está ausente na lista de aplicativos e no QuickLaunch. Acho que já sei como consertar isso. No gerenciador de arquivos, movo QtQuickApp.hpkg de ~config/packages para /system/packages.
Não, ainda está ausente. Aparentemente, eu (bem, e o guia) perdi algo.
Examinando a aba ‘Conteúdo’ no HaikuDepot para alguns outros aplicativos, vi que existem arquivos do tipo /data/mimedb/application/x-vnd... o que é ainda mais notável, /data/deskbar/menu/Applications/….
Bem, o que devo colocar lá? Vamos ver…
mkdir -p data/deskbar/menu/Applications/
( cd data/deskbar/menu/Applications ; ln -s ../../../../../apps/QtQuickApp . )
package add QtQuickApp.hpkg apps dataEstou bastante certo de que esse truque funcionará, mas ainda restam perguntas: por que isso é necessário, para que serve? Na minha opinião, isso prejudica a impressão geral de que o sistema é sofisticado.
Como explicou mr. waddlesplash:
Às vezes, há aplicativos que são necessários para outros aplicativos, mas não devem estar no menu. Por exemplo, o LegacyPackageInstaller na sua captura de tela, que lida com arquivos .pkg no formato BeOS. Queremos que os usuários os instalem, mas tê-los no menu causaria confusão.
Parece-me que há uma solução mais simples, por exemplo Hidden=true nos arquivos .desktop em Linux. Por que não tornar a informação ‘oculta’ um recurso e um atributo do sistema de arquivos?
O que não é particularmente sofisticado — o nome de (algum) aplicativo que mostra o menu, deskbar, está rigidamente vinculado no caminho.
mr. waddlesplash explica sobre isso:
"Deskbar" neste caso deve ser entendido como um termo geral (mais ou menos como "taskbar", que se refere tanto ao aplicativo do Windows quanto ao conceito geral). E já que isso
deskbar, e não "Deskbar", isso também pode ser entendido de forma semelhante.
2 diretórios "quase idênticos" com aplicativos dentro deles
Por que existem 2 diretórios com aplicativos, e por que em um deles meu QtQuickApplication está presente, enquanto no outro não? (Pois não é só um sistema, mas um segundo usuário, o que pessoalmente faria sentido para mim).
Estou realmente confuso e acho que seria bom unificar isso.
comentário mr. waddlesplash
No diretório Apps há aplicativos que não são necessários no menu. Mas a situação do menu realmente precisa ser melhorada, tornando-o mais personalizável.
Solicitação, ou isso não vai acontecer 😉
Eu pensei: é realmente necessário colocar aplicativos em /system/apps, se os usuários não devem vê-los lá. Talvez seja melhor colocá-los em outro lugar, onde o usuário não os encontre? Assim como é feito no Mac OS X, onde o conteúdo dos pacotes .app, que não deve ser visível para o usuário em /Applications, é escondido nas profundezas /System/Library/...«`.
E quanto às dependências?
Acho que é importante indicar as dependências, certo? Pode-se considerar o Qt uma parte obrigatória da instalação padrão do Haiku? Não! O Qt não está instalado por padrão. O construtor de pacotes pode identificar automaticamente as dependências verificando os arquivos ELF? Disseram-me que o HaikuPorter faz isso, mas pacote não. Tudo porque ele é apenas um "construtor de pacotes", que em si apenas cria arquivos hpkg.
Deveríamos tornar o Haiku mais refinado, adicionando uma política que proíbe um pacote de ter dependências de pacotes que não fazem parte de haikuports? (Мне бы так хотелось, поскольку подобная политика значительно облегчает задачу — система смогла бы автоматически разрешить зависимости каждого пакета, загружаемого откуда угодно, без возни с дополнительными источниками пакетов).
mr. waddlesplash esclarece:
Não gostaríamos de restringir tanto a liberdade dos desenvolvedores, pois é evidente que se a CompanyX quiser manter seu próprio conjunto de software com dependências (e, portanto, um repositório) — ela poderá fazê-lo livremente.
Nesse caso, talvez fosse melhor recomendar evitar que pacotes de terceiros tivessem dependências de qualquer coisa que não esteja no haikuports, incluindo tudo que é necessário junto com o aplicativo. Mas, acho que esse é um tópico para um futuro artigo desta série. [O autor está se referindo ao AppImage? — nota do tradutor]
Adicionando um ícone de aplicativo
E se eu quiser adicionar um dos ícones integrados bonitinhos aos recursos do meu novo aplicativo? Aparentemente, esse é um tópico fascinante, então será o foco do próximo artigo.
Como organizar a construção contínua de aplicativos?
Imagine um projeto semelhante ao Inkscape (sim, estou ciente de que ele ainda não está no Haiku, mas é conveniente para mostrar). Eles têm um repositório de código-fonte. https://gitlab.com/inkscape/inkscape.
Cada vez que alguém registra suas alterações no repositório, pipelines de build são acionados, após o que as correções são automaticamente testadas, o aplicativo é empacotado em diferentes formatos, incluindo AppImage para Linux (um pacote de aplicativo autônomo que pode ser baixado para testes locais independentemente do que pode ou não ser instalado no sistema). [eu sabia! — nota do tradutor]). Da mesma forma, tudo acontece em cada solicitação de mesclagem de branches, permitindo que você baixe o aplicativo construído a partir do código proposto na solicitação de mesclagem, mesmo antes da mesclagem.
Solicitações de mesclagem com status de build e a possibilidade de baixar os binários construídos em caso de build bem-sucedido (marcado em verde).
A construção é iniciada em contêineres Docker. O GitLab oferece runners gratuitos em Linux, e também acho que é possível conectar runners próprios (aliás, não consigo imaginar como isso funcionaria para sistemas como o Haiku, que, até onde sei, não têm Docker ou equivalente, mas também não há Docker para FreeBSD, então esse problema não é exclusivo do Haiku).
No ideal, a construção de aplicativos para Haiku poderia ser feita dentro de um contêiner Docker para Linux. Nessa situação, a construção para Haiku poderia ser integrada nos pipelines existentes. Existem cross-compilers? Ou seria necessário emular todo o Haiku dentro de um contêiner Docker, usando algo como QEMU/KVM (supondo que funcione assim dentro do Docker)? A propósito, muitos projetos usam princípios semelhantes. Por exemplo, o Scribus faz isso — já está disponível para Haiku. Um dia, chegarei ao ponto de conseguir enviar solicitações de mesclagem para outros projetos para adicionar suporte ao Haiku.
Um dos desenvolvedores explica:
Para outros projetos que desejam criar pacotes por conta própria, o método padrão CMake/CPack é suportado. Outros sistemas de construção podem ser suportados se a ferramenta de empacotamento for chamada diretamente, o que é bom, caso as pessoas estejam interessadas nisso. A experiência mostra que até agora não houve muito interesse, então o haikuporter trabalhou da forma que nos foi conveniente, mas, no final, ambas as abordagens devem funcionar em conjunto. Devemos apresentar um conjunto de ferramentas para a compilação cruzada de software a partir do Linux ou de qualquer outro sistema operacional de servidor (Haiku não é destinado ao uso em servidores).
Aplausos de pé. Usuários comuns de Linux carregam toda essa sobrecarga adicional e bagagem extra (segurança, controle rigoroso, etc.), que é necessária para sistemas operacionais de servidor, mas não para pessoais. Portanto, concordo plenamente que a capacidade de compilar aplicativos para o Haiku no Linux é o caminho certo.
Conclusão
A portabilidade de aplicativos POSIX para o Haiku é possível, mas pode exigir mais recursos do que uma simples recompilação. Eu certamente teria desistido dessa forma há muito tempo, se não fosse pela ajuda das pessoas no canal #haiku na rede irc.freenode.net. Mas mesmo eles nem sempre percebiam imediatamente o que estava errado.
Aplicativos escritos em Qt são uma exceção leve. Eu compilei um aplicativo de demonstração simples sem muitas dificuldades.
Compilar pacotes para aplicativos simples também é bastante fácil, mas apenas para aqueles 'lançados da maneira tradicional', ou seja, que têm arquivos de código-fonte versionados, destinados a suporte em haikuports. Para construção contínua (compilação a cada confirmação de alteração) no GitHub, as coisas não são tão simples. Aqui, o Haiku se sente mais semelhante a uma distribuição Linux do que a um resultado no Mac, onde pressionar o botão 'Compilar' no XCode resulta em um pacote .app, pronto para ser inserido na imagem do disco .dmg, preparado para upload no meu site.
A construção contínua de aplicativos com base em um sistema operacional 'servidor', como o Linux, provavelmente se tornará possível se houver demanda por parte dos desenvolvedores, mas, no momento, o projeto Haiku tem outras tarefas mais urgentes.
Experimente você mesmo! O projeto Haiku oferece imagens para download via DVD ou USB, geradas . Para instalação, basta baixar a imagem e gravá-la em um pen drive usando
Tem alguma dúvida? Convidamos você para o nosso canal em russo no .
Resumo de erros:
A partir de a tradução: este é o quinto artigo de uma série sobre o Haiku.
Lista de artigos:
Fonte: habr.com
