TL, DR: Um novato viu o Haiku pela primeira vez, tentando portar alguns programas do mundo Linux.
Meu primeiro programa portado do Haiku, empacotado em formato hpkg
Eu descobri o Haiku, um sistema operacional surpreendentemente bom para PCs.
Hoje aprenderei como portar novos programas para este sistema operacional. O foco principal é a descrição da primeira experiência de mudança para o Haiku do ponto de vista de um desenvolvedor Linux. Peço desculpas por quaisquer erros estúpidos que cometi ao longo do caminho, pois não se passou nem uma semana desde que baixei o Haiku pela primeira vez.
Quero alcançar três objetivos:
- Portar um aplicativo CLI simples
- Portar um aplicativo da GUI para o Qt
- Em seguida, empacote-os no formato hpkg (já que ainda estou pensando em adaptar AppDir e AppImage para Haiku...)
Vamos começar. Em seções и , bem como em do HaikuPorts encontrei a direção certa. Existe até um livro em PDF online .
467 páginas - e isso é de 1997! É assustador olhar para dentro, mas espero o melhor. As palavras do desenvolvedor são encorajadoras: “demorou muito porque o BeOS não era compatível com POSIX”, mas o Haiku “na maior parte” já é assim.
Portando um aplicativo CLI simples
A primeira ideia foi portar o aplicativo , mas, como se viu, isso já é a muito tempo atrás.
Primeira tentativa: nada para assistir
O que não consigo entender é que já - apesar do sistema operacional em si ainda não ser a versão 1.0.
Segunda tentativa: preciso reescrever
Então eu vou usar , CLI para controlar a impressora Brother P-Touch 770 que uso para imprimir etiquetas.
Imprimo várias etiquetas nele, e você já deve ter visto no artigo anterior. Um pouco antes, escrevi um pequeno programa wrapper GUI em Python (já que está em Gtk+, terá que ser reescrito, e este é um bom motivo para aprender).
Impressora de etiquetas Brother P-Touch 770. Funcionará com Haiku?
O gerenciador de pacotes Haiku conhece bibliotecas e comandos, portanto, se eu receber uma mensagem "não consigo encontrar libintl" ao executar configure - Acabei de lançar pkgman install devel:libintl e o pacote necessário será encontrado. Da mesma maneira pkgman install cmd:rsync. Bem, etc.
Exceto quando 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 baseado em Linux e, portanto, não exista para o Haiku. O que significa que preciso editar o código-fonte que estou tentando compilar.
Eh, você não pode pular e eu nem sei por onde começar.
Terceira tentativa
Seria bom ter tmate para o Haiku, 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 experimentar 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 foundNesta etapa eu abro o HaikuDepot e pesquiso curses.
Algo foi encontrado, o que me deu uma dica para uma consulta 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 foundMais uma vez fui ao HaikuDepot e, claro, encontrei devel:msgpack_c_cpp_devel. Quais são esses 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 1Nesta etapa, percebi que portar um programa para o Haiku requer muito mais conhecimento do que é necessário para uma simples reconstrução.
Conversei com os amigáveis desenvolvedores do Haiku, descobri que há um bug no msgpack e depois de alguns minutos vejo um patch no HaikuPorts. Posso ver com meus próprios olhos como o pacote corrigido (buildslave - máquinas virtuais).
Construindo o msgpack corrigido no buildmaster
Entre os tempos eu envio um patch para o upstream .
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?!
Volto ao problema 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 1Agora parece que o msgpack não é o culpado. estou comentando IMAXLABEL в tty.c como se segue:
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, lá vamos nós de novo... A propósito:
/Haiku/home/tmate> ./configure | grep -i OPENAT
checking for openat... nodiz 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 postei .
Eles me explicaram que há algo mais na libnetwork além da libresolv no Haiku. Aparentemente, o código precisa ser editado ainda mais. Preciso pensar…
find . -type f -exec sed -i -e 's|lresolv|lnetwork|g' {} ;A eterna questão: 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 foundA mesma coisa, só que de perfil. Pesquisei no Google e . Se você adicionar -lssp “às vezes” ajuda, eu tento:
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp"
(...)/Haiku/home/tmate> make
(...)/Haiku/home/tmate> ./tmateUau! Está começando! Mas…
[tmate] ssh.tmate.io lookup failure. Retrying in 2 seconds (non-recoverable failure in name resolution)vou tentar depurar :
/Haiku/home/tmate> strace -f ./tmate >log 2>&1“ID de porta incorreta” já é como um cartão de visita . Talvez alguém tenha uma ideia do que está errado e como consertar? Se sim, atualizarei o artigo. Link para .
Portando o 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!Muito simples. Menos de um minuto!
Empacotando aplicações em hpkg usando haikuporter e haikuports.
Com o que devo começar? Não existe uma documentação simples, vou ao canal #haiku em irc.freenode.net e ouço:
- Equipe
package- uma maneira de baixo nível de criar pacotes. Na maior parte, PackageInfo é suficiente para ela, conforme descrito na seção "Transformando-o em um pacote .hpkg adequado" - eu preciso fazer alguma coisa
- Pode usar (trava para mim, )
Não está claro o que fazer. Acho que preciso de um guia para iniciantes no estilo Hello World, de preferência um vídeo. Seria bom também ter uma introdução conveniente ao HaikuPorter, como é feito no GNU hello.
Eu li o seguinte:
haikuporteré uma ferramenta para criar projetos de pacotes comuns para o Haiku. Ele usa o repositório HaikuPorts como base para todos os pacotes. As receitas do Haikuporter são usadas para criar pacotes.
Além disso, descubro que:
Não há necessidade de armazenar receitas no armazenamento do HaikuPorts. Você pode criar outro repositório, colocar as receitas nele e apontar o haikuporter para ele.
Exatamente o que eu preciso - se não estiver procurando uma maneira de divulgar publicamente o pacote. Mas isso é assunto para outro post.
Instalando 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.confEscrevendo 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
}Montando a receita
Eu salvo o arquivo com o nome QtQuickApp-1.0.recipe, após o qual eu lanço aikuporter -S ./QuickApp-1.0.recipe. As dependências são verificadas para todos os pacotes no repositório , o que leva algum tempo. Vou tomar um café.
Por que diabos essa verificação deveria ser feita na minha máquina local, e não centralmente no servidor, uma vez para todos?
De acordo com o Sr. waddlesplash:
Com isso você pode reescrever qualquer arquivo do repositório 😉 Você pode otimizar um pouco isso, calculando as informações necessárias quando necessário, pois as últimas alterações feitas 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 repositoryAcontece que não existe um arquivo de receita normal que contenha o código-fonte do seu aplicativo. Você precisa mantê-lo em um repositório no formato HaikuPorts.
~/QtQuickApp> mv QtQuickApp-1.0.recipe ../haikuports/app-misc/QtQuickApp/
~/QtQuickApp> ../haikuport
~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipeEste fato torna a montagem mais complicada. Não gosto particularmente, mas acho que é necessário para que eventualmente todos os softwares de código aberto apareçam 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!Surgiu uma questão interessante. Se eu adicionar uma soma de verificação à receita - ela corresponderá ao último commit do git para integração contínua? (O desenvolvedor confirma: “Não vai funcionar. As receitas foram projetadas para serem relativamente estáveis.”)
Para se divertir, adicione à receita:
CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"Ainda não satisfeito:
~/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.gitO que ele está fazendo? Afinal, este é um 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 um descompactador se estiver acima da url do GitHub.
Talvez uri git:// funcione
SOURCE_URI="git://github.com/probonopd/QtQuickApp.git"Agora reclama assim:
Downloading: git://github.com/probonopd/QtQuickApp.git ...
Error: Downloading from unsafe sources is disabled in haikuports.conf!Hmm, por que tudo é tão complicado, por que você não pode “simplesmente trabalhar”? Afinal, não é incomum construir algo no GitHub. Sejam ferramentas que funcionam na hora, sem necessidade de configuração, ou como eu chamo de “complicação”.
Talvez funcione assim:
SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"Não. Eu ainda recebo esse erro estranho e faço,
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 tentando descompactar alguma coisa.
Conforme :
Pois é, o motivo foi o desejo de verificar a integridade dos dados recebidos para montagem. Uma das opções é verificar a soma de verificação do arquivo, mas você pode, é claro, fazer hash de arquivos individuais, o que não será implementado, porque leva muito mais tempo. A consequência disso é a “insegurança” do git e de outros VCS. Provavelmente será sempre assim, já que criar um arquivo no GitHub é bastante fácil e muitas vezes mais rápido. 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 2Por hábito, vou perguntar a boas pessoas no canal #haiku na rede irc.freenode.net. E onde eu estaria sem eles? Após a dica, percebi que deveria usar:
srcGitRev="d0769f53639eaffdcd070bddfb7113c04f2a0de8"
SOURCE_URI="https://github.com/probonopd/QtQuickApp/archive/$srcGitRev.tar.gz"
SOURCE_DIR="QtQuickApp-$srcGitRev"
CHECKSUM_SHA256="db8ab861cfec0ca201e9c7b6c0c9e5e828cb4e9e69d98e3714ce0369ba9d9522"Ok, ficou claro o que ele faz - baixa um arquivo com o código-fonte de uma determinada 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 branch master.
Um dos desenvolvedores explicou desta forma:
Temos nosso próprio CI, então tudo o que for colocado no repositório haikuports será empacotado para todos os usuários, e não queremos correr o risco de coletar e entregar “tudo na versão mais recente do upstream”.
Entendido! De qualquer forma, foi o que 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
(...)Ele repete isso ad infinitum. Aparentemente, isso é um erro (existe um aplicativo? Não consegui encontrar).
С haikuporter e repositório Não tem uma sensação de “simplesmente funciona”, mas como desenvolvedor, há algumas coisas que gosto em trabalhar com o Haiku. Na maior parte, é semelhante ao Open Build Service, um conjunto de ferramentas para construção de compilações Linux: extremamente poderoso, com uma abordagem sistemática, mas um exagero para meu pequeno aplicativo "olá mundo".
Novamente, de acordo com o Sr. waddlesplash:
Na verdade, o HaikuPorter é bastante rígido por padrão (além disso, há um modo lint e um modo estrito para torná-lo ainda mais rigoroso!), mas apenas porque ele cria pacotes que funcionarão, em vez de apenas criar pacotes. É por isso que ele reclama de dependências não declaradas, bibliotecas não importadas corretamente, versões incorretas, etc. O objetivo é detectar todo e qualquer problema, inclusive os futuros, antes que o usuário saiba (por isso não foi possível instalar o avrdude, pois a dependência estava realmente especificada na receita). Bibliotecas não são apenas pacotes individuais ou mesmo versões específicas de SO. O HaikuPorter garante que tudo isso seja observado nas próprias receitas para evitar erros durante a execução.
Em princípio, este nível de rigor justifica-se na criação de um sistema operativo, mas parece-me desnecessário para uma aplicação “olá mundo”. Decidi tentar outra coisa.
Construindo aplicativos no formato hpkg usando o comando “package create”
Talvez Instruções simples funcionarão 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 menuInesperadamente rápido, inesperadamente simples, inesperadamente eficaz. Exatamente como eu gosto, incrível!
Instalação - o que e onde?
Movido o arquivo QtQuickApp.hpkg para ~/config/packagesusando um gerenciador de arquivos, após o qual QtQuickApp apareceu magicamente em ~/config/apps.
Novamente, inesperadamente rápido, simples e eficaz. Incrível, incrível!
Mas... (onde estaríamos sem eles!)
O aplicativo ainda está faltando na lista do menu 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á desaparecido. Aparentemente, eu (bem, e as instruções) perdi alguma coisa.
Depois de olhar a guia "Conteúdo" no HaikuDepot para alguns outros aplicativos, vi que existem arquivos como /data/mimedb/application/x-vnd... o que é ainda mais notável é /data/deskbar/menu/Applications/….
Bem, o que devo colocar aí? Vamos...
mkdir -p data/deskbar/menu/Applications/
( cd data/deskbar/menu/Applications ; ln -s ../../../../apps/QtQuickApp . )
package add QtQuickApp.hpkg apps dataTenho certeza de que esse truque funcionará, mas as questões permanecem: por que isso é necessário, para que serve? Penso que isto estraga a impressão geral de que o sistema é tão sofisticado.
Como explicou o Sr. waddlesplash:
Às vezes, há aplicativos que outros aplicativos precisam, mas não estão no menu. Por exemplo, LegacyPackageInstaller em sua captura de tela, processando arquivos .pkg no formato BeOS. Gostaria que os usuários os instalassem, mas sua presença no menu causará confusão.
Por alguma razão, parece-me que existe uma solução mais simples, por exemplo Hidden=true em arquivos .desktop no Linux. Por que não tornar a informação “oculta” um recurso e atributo do sistema de arquivos?
O que não é especialmente sutil é o nome de (algum) aplicativo que mostra o menu, deskbar, rigidamente amarrado ao longo do caminho.
senhor. waddlesplash explica isso:
“Deskbar”, neste caso, deve ser entendido como uma espécie de termo geral (da mesma forma que “taskbar”, que se refere tanto ao aplicativo do Windows quanto ao conceito geral). Bem, já que isso
deskbar, não “Deskbar”, isso também pode ser entendido de forma semelhante.
2 diretórios "quase idênticos" com aplicativos neles
Por que existem 2 diretórios com aplicativos e também por que meu QtQuickApplication está em um, mas não no outro? (Afinal, este não é um sistema, mas um segundo usuário, o que seria compreensível para mim pessoalmente).
Estou muito confuso e acho que isso deveria ser unificado.
comentário do Sr. waddlesplash
O catálogo de Aplicativos contém 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 não vai acontecer 😉
Fiquei me perguntando: é realmente necessário hospedar aplicações em /system/apps, se os usuários os virem lá, isso é indesejável. Talvez fosse melhor colocá-los em outro local onde o usuário não os encontrasse? Assim como é feito no Mac OS X, onde o conteúdo dos pacotes .app, que não deve estar visível para o usuário em /Applications, escondendo-se nas profundezas de /System/Library/…“`.
E quanto às dependências?
Acho que vale a pena especificar as dependências de alguma forma, certo? O Qt pode ser considerado uma parte obrigatória da instalação do Haiku por padrão? Não! Qt não é instalado por padrão. Um construtor de pacotes pode detectar dependências automaticamente verificando arquivos ELF? Disseram-me que o HaikuPorter realmente faz isso, mas package Não. Isso porque é apenas um "construtor de pacotes" que cria arquivos por conta própria hpkg.
O Haiku deveria ser mais sofisticado adicionando uma política de que um pacote não deveria ter dependências de pacotes fora do Haiku? haikuports? (Eu gostaria, porque tal política tornaria as coisas muito mais fáceis - o sistema seria capaz de resolver automaticamente as dependências de cada pacote baixado de qualquer lugar, sem mexer em fontes de pacotes adicionais.)
senhor. waddlesplash explica:
Não gostaríamos de limitar tanto a liberdade dos desenvolvedores, porque é óbvio que se a CompanyX quiser oferecer suporte ao seu próprio conjunto de software com dependências (e, portanto, um repositório), o fará de forma totalmente livre.
Nesse caso, pode valer a pena recomendar que os pacotes de terceiros evitem dependências de qualquer coisa não incluída no haikuports, empacotando completamente tudo o que é necessário com o aplicativo. Mas acho que este é um tópico para um artigo futuro desta série. [O autor está caminhando para AppImage? - Aproximadamente. tradutor]
Adicionando um ícone de aplicativo
E se eu quiser adicionar um dos ícones integrados aos recursos do meu aplicativo recém-criado? Acontece que este é um tema incrível, por isso será a base para o próximo artigo.
Como organizar construções contínuas de aplicativos?
Imagine um projeto como o Inkscape (sim, sei que ainda não está disponível no Haiku, mas é conveniente exibi-lo). Eles têm um repositório de código-fonte https://gitlab.com/inkscape/inkscape.
Cada vez que alguém envia suas alterações para o repositório, pipelines de construção são iniciados, após os quais as alterações são automaticamente testadas, construídas e o aplicativo empacotado em vários pacotes, incluindo AppImage para Linux (um pacote de aplicativo independente que pode ser baixado para testes locais independentemente o que pode ou não estar instalado no sistema [Eu sabia! - Aproximadamente. tradutor]). O mesmo acontece com cada solicitação de mesclagem de ramificação, portanto, você pode baixar o aplicativo criado a partir do código proposto na solicitação de mesclagem antes da mesclagem.
Mesclar solicitações com status de compilação e a capacidade de baixar os binários compilados se a compilação for bem-sucedida (marcada em verde)
A construção é executada em contêineres Docker. O GitLab oferece executores gratuitos no Linux, e acho que pode ser possível incluir seus próprios executores (aliás, não vejo como isso funcionaria para sistemas como o Haiku, que sei que não tem Docker ou equivalente, mas também para o FreeBSD não há Docker, então esse problema não é exclusivo do Haiku).
Idealmente, os aplicativos Haiku podem ser construídos dentro de um contêiner Docker para Linux. Nesta situação, a montagem do Haiku pode ser introduzida em pipelines existentes. Existem compiladores cruzados? Ou devo emular todo o Haiku dentro de um contêiner Docker usando algo como QEMU/KVM (assumindo que funcionará dessa maneira dentro do Docker)? A propósito, muitos projetos utilizam princípios semelhantes. Por exemplo, o Scribus faz isso - já está disponível para Haiku. Um dia chegará o dia em que poderei enviar Envie solicitações 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 CMake/CPack regular é suportado. Outros sistemas de compilação podem ser suportados chamando diretamente o programa de compilação do pacote, o que é bom se as pessoas estiverem interessadas nele. A experiência mostra: até agora não houve muito interesse, então o haikuporter funcionou da maneira mais conveniente para nós, mas, em última análise, os dois métodos devem funcionar juntos. Deveríamos introduzir um conjunto de ferramentas para construção cruzada de software do Linux ou de qualquer outro sistema operacional de servidor (o Haiku não foi projetado para rodar em servidores).
Eu aplaudo de pé. Os usuários regulares do Linux carregam toda essa carga adicional e bagagem adicional (segurança, controle rigoroso, etc.) que é necessária para um sistema operacional de servidor, mas não para um sistema pessoal. Portanto, concordo plenamente que ser capaz de criar aplicativos Haiku no Linux é o caminho a seguir.
Conclusão
Portar aplicativos POSIX para o Haiku é possível, mas pode ser mais caro do que uma reconstrução típica. Eu definitivamente ficaria preso nisso por muito tempo se não fosse pela ajuda das pessoas do 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 fácil. Montei um aplicativo de demonstração simples sem problemas.
Construir um pacote para aplicações simples também é bastante fácil, mas apenas para aquelas “lançadas tradicionalmente”, ou seja, ter arquivos de código-fonte versionados destinados ao suporte em haikuports. Para uma construção contínua (construção para cada commit de alterações) com GitHub, tudo parece não ser tão simples. Aqui o Haiku parece mais uma distribuição Linux do que o resultado em um Mac, onde quando você clica no botão “Construir” no XCode você obtém um pacote .app, pronto para ser inserido em uma imagem de disco .dmg, preparado para download no meu site.
A construção contínua de aplicativos baseados em um sistema operacional de “servidor”, por exemplo, Linux, provavelmente se tornará possível se houver demanda por parte dos desenvolvedores, mas no momento o projeto Haiku tem outras tarefas mais urgentes.
Tente você mesmo! Afinal, o projeto Haiku disponibiliza imagens para inicialização a partir de DVD ou USB, geradas . Para instalar, basta baixar a imagem e gravá-la em uma unidade flash USB usando
Você tem alguma pergunta? Nós convidamos você para o idioma russo .
Visão geral do erro:
De tradução: este é o quinto artigo da série sobre Haiku.
Lista de artigos:
Fonte: habr.com