🥇Mój piąty dzień z Haiku: przeportujmy kilka programów

TL; DR: Nowicjusz po raz pierwszy zetknął się z Haiku, próbując przenieść niektóre programy ze świata Linuksa.

Mój pierwszy program przeniesiony na Haiku, spakowany w formacie hpkg

Niedawno Odkryłem Haiku, zaskakująco dobry system operacyjny dla komputerów PC.
Dzisiaj dowiem się jak przenieść nowe programy na ten system operacyjny. Główny nacisk położony jest na opis pierwszego doświadczenia przejścia na Haiku z punktu widzenia programisty Linuksa. Przepraszam za wszelkie głupie błędy, które popełniłem po drodze, ponieważ nie minął nawet tydzień, odkąd po raz pierwszy pobrałem Haiku.

Chcę osiągnąć trzy cele:

Przeportuj prostą aplikację CLI
Przenieś aplikację z GUI do Qt
Następnie spakuj je w formacie hpkg (ponieważ wciąż zastanawiam się nad adaptacją AppDir i AppImage dla Haiku...)

Zacznijmy. W sekcjach dokumentacja и rozwój, jak również w wiki z HaikuPorts znalazłem właściwy kierunek. Dostępna jest nawet książka online w formacie PDF BeOS: przenoszenie aplikacji uniksowej.
467 stron - i to z 1997 roku! Strach zajrzeć do środka, ale mam nadzieję, że wszystko będzie dobrze. Słowa dewelopera są zachęcające: „zajęło to dużo czasu, ponieważ BeOS nie był zgodny z POSIX”, ale Haiku „w większości” już takie jest.

Przenoszenie prostej aplikacji CLI

Pierwszą myślą było przeniesienie aplikacji avrdude, ale jak się okazało, to już jest zrobiłem dawno temu.

Pierwsza próba: nic do oglądania

Czego nie mogę zrozumieć, to już tego Aplikacje są przenoszone do Haiku od ponad 10 lat - pomimo tego, że sam system operacyjny nie jest jeszcze nawet w wersji 1.0.

Druga próba: trzeba napisać od nowa

Więc skorzystam ptouch-770, CLI do sterowania drukarką Brother P-Touch 770, której używam do drukowania etykiet.
Drukuję na nim różne etykiety, być może widzieliście to już w poprzednim artykule. Nieco wcześniej napisałem mały program do pakowania GUI w Pythonie (ponieważ jest w Gtk+, trzeba go będzie napisać od nowa, a to dobry powód, żeby się uczyć).

Drukarka etykiet Brother P-Touch 770. Czy będzie działać z Haiku?

Menedżer pakietów Haiku wie o bibliotekach i poleceniach, więc jeśli podczas działania otrzymam komunikat „nie można znaleźć libintl” configure - Właśnie uruchamiam pkgman install devel:libintl i wymagany pakiet zostanie znaleziony. Podobnie pkgman install cmd:rsync. Cóż, itp.

Z wyjątkiem sytuacji, gdy to nie działa:

/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

Być może udev jest zbyt oparty na Linuksie i dlatego nie istnieje dla Haiku. Oznacza to, że muszę edytować kod źródłowy, który próbuję skompilować.
Ech, nie da się przeskoczyć przez głowę i nawet nie wiem od czego zacząć.

Trzecia próba

Byłoby miło mieć tmate w przypadku Haiku, wtedy pozwoliłbym programistom Haiku połączyć się z moją sesją terminalową - na wypadek, gdyby coś poszło nie tak. Instrukcje są dość proste:

./autogen.sh
./configure
make
make install

Wygląda dobrze, więc dlaczego nie wypróbować tego na 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

W tym kroku otwieram HaikuDepot i wyszukuję curses.
Znaleziono coś, co dało mi wskazówkę do bardziej kompetentnego zapytania:

/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

Znowu poszedłem do HaikuDepot i oczywiście znalazłem devel:msgpack_c_cpp_devel. Co to za dziwne nazwy?

/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

Na tym etapie zdałem sobie sprawę, że przeniesienie programu na Haiku wymaga znacznie większej wiedzy, niż jest to potrzebne do prostej przebudowy.
Rozmawiałem z zaprzyjaźnionymi twórcami Haiku, okazuje się, że jest błąd w msgpacku, a po kilku minutach widzę łatkę w HaikuPorts. Widzę na własne oczy jak wygląda poprawiona paczka idę tutaj (buildslave - maszyny wirtualne).

Budowanie poprawionego pakietu msgpack na buildmaster

W międzyczasie wysyłam łatkę do źródła aby dodać obsługę Haiku do msgpack.

Pięć minut później zaktualizowany msgpack jest już dostępny w 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.

Nieoczekiwanie dobre. Czy ja to powiedziałem?!

Wracam do pierwotnego problemu:

/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

Teraz wygląda na to, że nie jest to wina msgpack. komentuję IMAXLABEL в tty.c w następujący sposób:

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

Wynik:

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.

No cóż, zaczynamy jeszcze raz... A tak przy okazji:

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

Pan. plusk mówi ci, gdzie kopać:

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

Tutaj zamieściłem dziennik konfiguracji.

Wyjaśnili mi, że oprócz libresolv na Haiku w libnetwork jest coś jeszcze. Najwyraźniej kod wymaga dalszej edycji. Muszę pomyśleć…

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

Odwieczne pytanie: co się dzieje?

/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

To samo, tylko z profilu. Wygooglowałem i Znajdź to. Jeśli dodasz -lssp „Czasami” pomaga, próbuję:

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

Wow! Zaczyna się! Ale…

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

Spróbuję zdebugować plik tutaj:

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

„Zły identyfikator portu” jest już jak wizytówka haiku. Może ktoś ma pomysł co jest nie tak i jak to naprawić? Jeśli tak, zaktualizuję artykuł. Łączyć z GitHub.

Przeniesienie aplikacji GUI do Qt.

Wybieram prostą aplikację QML.

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

Naprawdę proste. Mniej niż minutę!

Aplikacje pakujące w hpkg przy użyciu haikuporter i haikuports.

Od czego powinienem zacząć? Nie ma prostej dokumentacji, wchodzę na kanał #haiku na irc.freenode.net i słyszę:

Zespół package - niskopoziomowy sposób tworzenia pakietów. W większości wystarczy jej PackageInfo, jak opisano w sekcji „Przetwarzanie z tego odpowiedniego pakietu .hpkg”
muszę coś zrobić такое
Można użyć kreator hpkg (u mnie się zawiesza, zgłaszanie błędów)

Nie jest jasne, co robić. Chyba potrzebuję przewodnika dla początkujących w stylu Hello World, najlepiej w formie wideo. Byłoby miło mieć także wygodne wprowadzenie do HaikuPorter, tak jak ma to miejsce w GNU hello.

Czytam co następuje:

haikuporter to narzędzie do tworzenia wspólnych projektów pakietów dla Haiku. Wykorzystuje repozytorium HaikuPorts jako bazę dla wszystkich pakietów. Do tworzenia pakietów wykorzystywane są receptury Haikuporter.

Dodatkowo dowiaduję się, że:

Nie ma potrzeby przechowywania przepisów w pamięci HaikuPorts. Możesz stworzyć kolejne repozytorium, umieścić w nim przepisy, a następnie wskazać haikuporterowi.

Właśnie tego potrzebuję - jeśli nie szukam sposobu na publiczne udostępnienie pakietu. Ale to temat na inny wpis.

Instalowanie haikuportera i 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

Pisanie przepisu

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
}

Składanie przepisu

Zapisuję plik pod nazwą QtQuickApp-1.0.recipe, po czym uruchamiam aikuporter -S ./QuickApp-1.0.recipe. Zależności są sprawdzane dla wszystkich pakietów w repozytorium haikuporty, co zajmuje trochę czasu. Pójdę po kawę.

Dlaczego, do cholery, należy to sprawdzić na moim komputerze lokalnym, a nie centralnie na serwerze raz dla wszystkich?

Według pana. plusk wody:

Dzięki takiemu, że będziesz mógł przepisać dowolny plik w repozytorium 😉 Można to trochę zoptymalizować, doliczając niezbędne informacje w razie potrzeby, bo ostatnio wprowadzane zmiany są dość rzadkie.

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

Okazuje się, że nie ma czegoś takiego jak zwykły plik z przepisami zawierający kod źródłowy aplikacji. Musisz przechowywać go w repozytorium w formacie HaikuPorts.

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

Fakt ten sprawia, że montaż jest bardziej uciążliwy. Niezbyt mi się to podoba, ale uważam, że jest to konieczne, aby w końcu całe oprogramowanie open source pojawiło się w HaikuPorts.

Otrzymuję co następuje:

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

Co jest nie tak? Po przeczytaniu irc robię:

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

Pojawiło się ciekawe pytanie. Jeśli dodam sumę kontrolną do przepisu - czy będzie ona zgodna z najnowszym zatwierdzeniem git w celu zapewnienia ciągłej integracji? (Deweloper potwierdza: „To nie zadziała. Przepisy zostały zaprojektowane tak, aby były stosunkowo stabilne.”)

Dla zabawy dodaj do przepisu:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Wciąż niezadowolony:

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

Co on robi? W końcu jest to repozytorium git, kod już tam jest, nie ma co rozpakowywać. Z mojego punktu widzenia narzędzie powinno być na tyle inteligentne, aby nie szukać narzędzia rozpakowującego, jeśli znajduje się ono powyżej adresu URL GitHub.

Być może uri git:// będzie działać

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

Teraz narzeka tak:

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

Hmm, dlaczego wszystko jest takie skomplikowane, dlaczego nie można „po prostu pracować”? W końcu nierzadko zdarza się, że buduje się coś na GitHubie. Niezależnie od tego, czy chodzi o narzędzia, które działają od razu, bez konieczności konfiguracji, czy jak to nazywam „zamieszanie”.

Może to będzie działać tak:

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

Nie. Nadal wyskakuje mi ten dziwny błąd i robię to, jak opisano tutaj

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

Posuwam się trochę dalej, ale dlaczego na mnie krzyczy (GitHub nie jest bezpieczny!) i wciąż próbuje coś rozpakować.

Według Pan. plusk:

No tak, powodem była chęć sprawdzenia integralności danych otrzymanych do montażu. Jedną z możliwości jest weryfikacja sumy kontrolnej archiwum, ale można oczywiście hashować poszczególne pliki, co nie zostanie zaimplementowane, bo trwa to znacznie dłużej. Konsekwencją tego jest „niepewność” gita i innych VCS-ów. Najprawdopodobniej tak będzie zawsze, ponieważ utworzenie archiwum na GitHubie jest dość łatwe i często szybsze. Cóż, być może w przyszłości komunikat o błędzie nie będzie tak krzykliwy... (nie łączymy już takich przepisów w 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

Ze starego przyzwyczajenia chodzę pytać dobrych ludzi na kanale #haiku w sieci irc.freenode.net. A gdzie byłbym bez nich? Po podpowiedzi zdałem sobie sprawę, że powinienem użyć:

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

OK, stało się jasne, co robi - pobiera archiwum z kodem źródłowym określonej wersji. Z mojego punktu widzenia jest to głupie i niezupełnie to, czego chciałem, a mianowicie pobrać najnowszą wersję z gałęzi master.

Jeden z twórców wyjaśnił to w ten sposób:

Posiadamy własny CI, więc wszystko, co zostanie umieszczone w repozytorium haikuports, zostanie spakowane dla wszystkich użytkowników, a nie chcemy ryzykować gromadzenia i dostarczania „wszystko w najnowszej wersji upstream”.

Zrozumiany! W każdym razie stało się tak:

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

Powtarza to w nieskończoność. Najwyraźniej jest to błąd (czy istnieje aplikacja? Nie mogłem jej znaleźć).

С haikuporter i repozytorium haikuporty Nie ma wrażenia, że „po prostu działa”, ale jako programista lubię pewne rzeczy w pracy z Haiku. W przeważającej części jest podobny do Open Build Service, zestawu narzędzi do tworzenia kompilacji Linuksa: niezwykle potężny, z systematycznym podejściem, ale przesadny dla mojej małej aplikacji „hello world”.

Znów według pana. plusk wody:

Rzeczywiście, HaikuPorter jest domyślnie dość rygorystyczny (dodatkowo istnieje tryb lint, a także tryb ścisły, aby uczynić go jeszcze bardziej rygorystycznym!), ale tylko dlatego, że tworzy pakiety, które będą działać, a nie tylko tworzenie pakietów. Dlatego narzeka na niezadeklarowane zależności, niepoprawne zaimportowanie bibliotek, nieprawidłowe wersje itp. Celem jest wyłapanie wszelkich problemów, łącznie z przyszłymi, zanim użytkownik się o tym dowie (dlatego nie można było zainstalować avrdude, ponieważ zależność była faktycznie określona w przepisie). Biblioteki to nie tylko pojedyncze pakiety czy nawet określone wersje SO. HaikuPorter zapewnia, że wszystko to jest przestrzegane w samych przepisach, aby uniknąć błędów podczas wykonywania.

W zasadzie taki poziom rygoru jest uzasadniony przy tworzeniu systemu operacyjnego, ale wydaje mi się, że jest on niepotrzebny w przypadku aplikacji „hello world”. Postanowiłem spróbować czegoś innego.

Tworzenie aplikacji w formacie hpkg za pomocą polecenia „package create”.

Może, to Czy proste instrukcje będą dla mnie lepsze?

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

Niespodziewanie szybki, nieoczekiwanie prosty, nieoczekiwanie skuteczny. Dokładnie tak jak lubię, rewelacja!

Instalacja – co i gdzie?

Przeniesiono plik QtQuickApp.hpkg do ~/config/packagesza pomocą menedżera plików, po czym w magiczny sposób pojawiła się QtQuickApp ~/config/apps.
Znowu nieoczekiwanie szybko, prosto i skutecznie. Niesamowite, niesamowite!

Ale... (kim byśmy byli bez nich!)

Aplikacji nadal nie ma na liście menu aplikacji i w aplikacji QuickLaunch. Chyba już wiem jak to naprawić. W menedżerze plików przenoszę QtQuickApp.hpkg z ~/config/packages do /system/packages.

Nie, nadal brakuje. Najwyraźniej coś przeoczyłem (no cóż, i instrukcje).

Po przejrzeniu zakładki „Zawartość” w HaikuDepot w poszukiwaniu innych aplikacji, zauważyłem, że znajdują się tam pliki takie jak /data/mimedb/application/x-vnd... co jest jeszcze bardziej niezwykłe /data/deskbar/menu/Applications/….

No i co mam tam umieścić? Pospiesz się...

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

Jestem pewien, że ta sztuczka zadziała, ale pozostają pytania: dlaczego jest to konieczne i do czego to służy? Myślę, że psuje to ogólne wrażenie, że system jest tak wyrafinowany.

Jak wyjaśnił p. plusk wody:

Czasami istnieją aplikacje, których potrzebują inne aplikacje, ale których nie ma w menu. Na przykład LegacyPackageInstaller na zrzucie ekranu przetwarzający archiwa .pkg w formacie BeOS. Chciałbym, żeby użytkownicy je instalowali, ale ich obecność w menu spowoduje zamieszanie.

Z jakiegoś powodu wydaje mi się, że istnieje na przykład prostsze rozwiązanie Hidden=true w plikach .desktop na Linuksie. Dlaczego nie uczynić „ukrytych” informacji zasobem i atrybutem systemu plików?

To, co szczególnie nie jest subtelne, to nazwa (jakiejś) aplikacji wyświetlającej menu, deskbar, sztywno przywiązany po drodze.

Pan. waddlesplash wyjaśnia to:

„Pasek pulpitu” w tym przypadku należy rozumieć jako swego rodzaju pojęcie ogólne (w podobny sposób, jak „pasek zadań”, który odnosi się zarówno do aplikacji Windows, jak i ogólnej koncepcji). Cóż, od tego deskbar, a nie „Pasek pulpitu”, można to również rozumieć w podobny sposób.

2 „prawie identyczne” katalogi z zawartymi w nich aplikacjami

Dlaczego istnieją 2 katalogi z aplikacjami i dlaczego moja aplikacja QtQuickApplication znajduje się w jednym, a nie w drugim? (Przecież to nie jest jeden system, a drugi użytkownik, co byłoby dla mnie osobiście zrozumiałe).
Jestem naprawdę zdezorientowany i myślę, że należy to ujednolicić.

komentarz pana. plusk

Katalog aplikacji zawiera aplikacje, które nie są potrzebne w menu. Ale sytuacja z menu naprawdę wymaga poprawy, aby była bardziej konfigurowalna.

Zgłoszenie, bo inaczej się nie stanie 😉

Zastanawiałem się: czy naprawdę konieczne jest hostowanie aplikacji w /system/apps, jeśli użytkownicy je tam zobaczą, jest to niepożądane. Może lepiej byłoby umieścić je w innym miejscu, w którym użytkownik ich nie spotka? Podobnie jak to się robi w Mac OS X, gdzie zawartość pakietów .app, które nie powinny być widoczne dla użytkownika w /Applications, ukrywając się w głębinach /System/Library/…„`.

A co z zależnościami?

Myślę, że warto jakoś doprecyzować zależności, prawda? Czy Qt można domyślnie uznać za obowiązkową część instalacji Haiku? Nie! Qt nie jest domyślnie instalowany. Czy konstruktor pakietów może automatycznie wykryć zależności, sprawdzając pliki ELF? Powiedziano mi, że HaikuPorter faktycznie to robi, ale package NIE. Dzieje się tak dlatego, że jest to po prostu „konstruktor pakietów”, który samodzielnie tworzy pliki hpkg.

Czy Haiku powinno być bardziej wyrafinowane poprzez dodanie zasady mówiącej, że pakiet nie powinien mieć zależności od pakietów spoza Haiku? haikuports? (Chciałbym, ponieważ taka polityka znacznie ułatwiłaby sprawę - system byłby w stanie automatycznie rozwiązać zależności każdego pakietu pobranego z dowolnego miejsca, bez konieczności grzebania w dodatkowych źródłach pakietów.)

Pan. waddlesplash wyjaśnia:

Nie chcielibyśmy tak bardzo ograniczać swobody programistów, bo oczywiste jest, że jeśli CompanyX będzie chciała wspierać własny zestaw oprogramowania z zależnościami (a co za tym idzie repozytorium), zrobi to całkowicie swobodnie.

W takim przypadku warto zalecić, aby pakiety stron trzecich unikały zależności od czegokolwiek, co nie jest zawarte w haikuports, poprzez całkowite pakowanie wszystkiego, co potrzebne w aplikacji. Myślę jednak, że jest to temat na kolejny artykuł z tej serii. [Czy autor zmierza w stronę AppImage? - około. tłumacz]

Dodanie ikony aplikacji

A co jeśli będę chciał dodać jedną z zgrabnych wbudowanych ikonek do zasobów mojej nowo utworzonej aplikacji? Okazuje się, że jest to niesamowity temat, dlatego będzie podstawą kolejnego artykułu.

Jak zorganizować ciągłe budowanie aplikacji?

Wyobraźcie sobie projekt typu Inkscape (tak, wiem, że nie jest on jeszcze dostępny w Haiku, ale wygodnie się na nim wyświetla). Mają repozytorium kodu źródłowego https://gitlab.com/inkscape/inkscape.
Za każdym razem, gdy ktoś zatwierdzi zmiany w repozytorium, uruchamiane są potoki kompilacji, po czym zmiany są automatycznie testowane, budowane, a aplikacja pakowana w różne pakiety, w tym AppImage dla systemu Linux (samodzielny pakiet aplikacji, który można pobrać do lokalnych testów niezależnie od co może, a co nie, zostać zainstalowane w systemie [Wiedziałam! - około. tłumacz]). To samo dzieje się z każdym żądaniem połączenia oddziałów, więc przed połączeniem możesz pobrać aplikację zbudowaną z kodu zaproponowanego w żądaniu połączenia.

Połącz żądania ze statusami kompilacji i możliwością pobrania skompilowanych plików binarnych, jeśli kompilacja się powiedzie (zaznaczone na zielono)

Kompilacja działa w kontenerach Docker. GitLab oferuje bezpłatne programy uruchamiające w systemie Linux i myślę, że możliwe byłoby dodanie własnych modułów uruchamiających (nawiasem mówiąc, nie wiem, jak to zadziałałoby w przypadku systemów takich jak Haiku, o których wiem, że nie mają Dockera ani jego odpowiednika, ale również dla FreeBSD nie ma Dockera, więc ten problem nie jest unikalny dla Haiku).

W idealnym przypadku aplikacje Haiku można zbudować w kontenerze Docker dla systemu Linux. W tej sytuacji montaż Haiku można wprowadzić w istniejące rurociągi. Czy istnieją kompilatory krzyżowe? A może powinienem emulować całe Haiku w kontenerze Dockera, używając czegoś takiego jak QEMU/KVM (zakładając, że będzie to działać w ten sposób w Dockerze)? Nawiasem mówiąc, wiele projektów opiera się na podobnych zasadach. Robi to na przykład Scribus - jest już dostępny dla Haiku. Pewnego dnia nadejdzie dzień, kiedy będę mógł wysłać taki Przeciągnij żądania do innych projektów, aby dodać obsługę Haiku.

Jeden z twórców wyjaśnia:

W przypadku innych projektów, które chcą samodzielnie tworzyć pakiety, obsługiwana jest zwykła metoda CMake/CPack. Inne systemy kompilacji mogą być obsługiwane poprzez bezpośrednie wywołanie programu kompilacji pakietu, co jest w porządku, jeśli ludzie są nim zainteresowani. Doświadczenie pokazuje: jak dotąd nie było dużego zainteresowania, więc haikuporter działał dla nas w miarę wygodnie, ale ostatecznie obie metody powinny ze sobą współpracować. Powinniśmy wprowadzić zestaw narzędzi do cross-buildingu oprogramowania z Linuksa lub dowolnego innego serwerowego systemu operacyjnego (Haiku nie jest przeznaczone do uruchamiania na serwerach).

Daję owację na stojąco. Zwykli użytkownicy Linuksa niosą ze sobą całe to dodatkowe obciążenie i dodatkowy bagaż (bezpieczeństwo, ścisła kontrola itp.), który jest niezbędny dla systemu operacyjnego serwera, ale nie dla osobistego. Dlatego całkowicie zgadzam się, że najlepszym rozwiązaniem będzie możliwość tworzenia aplikacji Haiku w systemie Linux.

wniosek

Przenoszenie aplikacji POSIX na Haiku jest możliwe, ale może być droższe niż typowa przebudowa. Na pewno tkwiłbym w tym jeszcze długo, gdyby nie pomoc osób z kanału #haiku w sieci irc.freenode.net. Ale nawet oni nie zawsze od razu widzieli, co było nie tak.

Aplikacje napisane w Qt są łatwym wyjątkiem. Bez żadnych problemów stworzyłem prostą aplikację demonstracyjną.

Zbudowanie pakietu dla prostych aplikacji również jest dość łatwe, ale tylko dla tych „tradycyjnie wydawanych”, czyli tzw. posiadanie wersjonowanych archiwów kodu źródłowego przeznaczonych do obsługi w haikuportach. W przypadku ciągłej kompilacji (kompilacji przy każdym zatwierdzeniu zmian) za pomocą GitHuba wszystko wydaje się nie takie proste. Tutaj Haiku bardziej przypomina dystrybucję Linuksa niż wynik na komputerze Mac, gdzie po kliknięciu przycisku „Buduj” w XCode otrzymasz pakiet .app, gotowy do wstawienia do obrazu dysku .dmg, przygotowany do pobrania na mojej stronie internetowej.
Ciągłe budowanie aplikacji w oparciu o „serwerowy” system operacyjny, np. Linux, najprawdopodobniej stanie się możliwe, jeśli będzie zapotrzebowanie ze strony programistów, ale w tej chwili projekt Haiku ma inne, pilniejsze zadania.

Spróbuj sam! W końcu projekt Haiku udostępnia generowane obrazy do rozruchu z DVD lub USB codziennie. Aby zainstalować, wystarczy pobrać obraz i zapisać go na dysku flash za pomocą Akwaforcista

Czy masz jakieś pytania? Zapraszamy na zajęcia rosyjskojęzyczne kanał telegramu.

Przegląd błędów: Jak strzelić sobie w stopę w C i C++. Zbiór przepisów Haiku OS

Od autor tłumaczenie: to piąty artykuł z serii o Haiku.

Lista artykułów: pierwszy Drugi trzeci Po czwarte

Źródło: www.habr.com

Mój piąty dzień z Haiku: przeportujmy kilka programów