🥇Mój piąty dzień z Haiku: portujmy trochę programów

TL;DR: Nowicjusz po raz pierwszy zobaczył Haiku, próbuje portować niektóre programy ze świata Linuxa.

Moja pierwsza portowana aplikacja dla Haiku, spakowana w format hpkg

Niedawno Odkryłem Haiku, niespodziewanie dobrą operacyjną system dla PC.
Dziś będę uczyć się przenosić nowe programy na ten system operacyjny. Główny nacisk kładę na opis pierwszych doświadczeń z przejściem na Haiku z perspektywy dewelopera Linux. Przepraszam za głupie błędy popełnione w trakcie tego procesu, ponieważ od momentu, gdy po raz pierwszy załadowałem Haiku, minęło zaledwie kilka dni.

Chcę osiągnąć trzy cele:

Zportować prostą aplikację CLI
Zportować aplikację z GUI w Qt
Następnie spakować je w format hpkg (ponieważ wciąż myślę o dostosowaniu AppDir i AppImage dla Haiku...)

Zaczynajmy. W sekcjach 文档 i opracowywanie, a także w wiki z HaikuPorts znalazłem odpowiedni kierunek. Jest nawet internetowa książka PDF BeOS: Portowanie aplikacji Unix.
467 stron – a to już od 1997 roku! Zerknąć do środka to przerażająca myśl, ale mam nadzieję na lepsze. Pocieszające są słowa dewelopera: «to zajmie dużo czasu, ponieważ BeOS nie była zgodna z POSIX», natomiast Haiku «pod wieloma względami» już taka jest.

Portowanie prostej aplikacji CLI

Pierwszą myślą było zportować aplikację avrdude, ale jak się okazało, to już przeprowadzili dawno temu.

Pierwsza próba: nie ma na co patrzeć

Nie mogę zrozumieć, że już od ponad 10 lat aplikacje są portowane dla Haiku — przy czym sama OS jeszcze nie ma wersji 1.0.

Druga próba: trzeba przepisać

Tak więc, będę używać ptouch-770, CLI do zarządzania drukarką Brother P-Touch 770, na której drukuję etykiety.
Drukuję na niej różne etykiety i być może już ją widziałeś w poprzednim artykule. Chwilę wcześniej napisałem mały program owijkowy z GUI w Pythonie (ponieważ jest na Gtk+ — będzie trzeba go przepisać, co jest dobrą okazją do nauki).

Drukarka etykiet Brother P-Touch 770. Czy zadziała pod Haiku?

Menadżer pakietów Haiku zna biblioteki i polecenia, dlatego jeśli dostaję komunikat «cannot find libintl» po uruchomieniu configure — po prostu uruchamiam pkgman install devel:libintl i potrzebny pakiet zostanie znaleziony. Podobnie pkgman install cmd:rsync. Cóż, itd.

Z wyjątkiem przypadków, 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

Może udev jest zbyt linuksowy, dlatego nie istnieje dla Haiku. Co oznacza konieczność edytowania kodu źródłowego, który próbuję skompilować.
Ech, trudno przeskoczyć samego siebie, a nawet nie wiem, od czego zacząć.

Trzecia próba

Fajnie byłoby mieć tmate dla Haiku, wtedy pozwoliłbym deweloperom Haiku połączyć się z moją sesją terminala — na wypadek, gdyby coś poszło nie tak. Instrukcje są wystarczająco proste:

.\/autogen.sh
.\/configure
make
make install

Wygląda nieźle, więc czemu nie spró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

Na tym etapie otwieram HaikuDepot i szukam curses.
Coś się znalazło, co dało mi wskazówkę do bardziej trafnego 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. Jakie 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 zrozumiałem, że przeniesienie programu na Haiku wymaga znacznie większej wiedzy, niż potrzebnej do prostego przebudowy.
Porozmawiałem z przyjaznymi deweloperami Haiku, okazało się, że jest błąd w msgpack, a po kilku minutach widzę patch w HaikuPorts. Na własne oczy obserwuję, jak poprawiony pakiet buduje się tutaj (buildslave — maszyny wirtualne).

Budowa poprawionego msgpack na buildmaster

W międzyczasie wysyłam patch do upstream aby dodać wsparcie dla Haiku w 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.

Zaskakująco dobrze. To powiedziałem?!

Wracam do pierwotnego zadania:

/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 wydaje się, że msgpack nie jest winny. Komentuję IMAXLABEL do tty.c tak:

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

Wynik:

osdep-unknown.c: W funkcji 'osdep_get_cwd':
osdep-unknown.c:32:19: ostrzeżenie: nieużywany parametr 'fd' [-Wunused-parameter]
osdep_get_cwd(int fd)
               ~~~~^~
make: *** Nie ma reguły do zrobienia celu 'compat\/forkpty-unknown.c', potrzebne przez 'compat\/forkpty-unknown.o'.  Stop.

No i znowu… A propos:

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

mr. waddlesplash sugeruje, 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 wrzuciłem config.log.

Wyjaśniono mi, że do libresolv na Haiku jest coś jeszcze w libnetwork. Najwyraźniej trzeba dalej poprawić kod. Muszę pomyśleć…

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

Wieczne 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 w profil. Wyszukałem i znalazłem 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! Działa! Ale…

[tmate] ssh.tmate.io lookup failure. Ponawianie za 2 sekundy (niemożliwy do odzyskania błąd w rozpoznawaniu nazwy)

Spróbuję debugować, plik tutaj:

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

„Zły identyfikator portu” — to już jak wizytówka haiku.Może ktoś ma pojęcie, co jest nie tak i jak to naprawić? Jeśli coś, zaktualizuję artykuł. Link do GitHub.

Portowanie aplikacji GUI na 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ę!

Pakowanie aplikacji w hpkg za pomocą haikuporter i haikuports.

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

Zespół pakiet — niskopoziomowy sposób tworzenia pakietów. W większości wystarczy PackageInfo, jak opisano w sekcji „Zrobienie z tego prawidłowego pakietu .hpkg”
Muszę coś zrobić takiej
Można używać hpkg-creator (wywala mnie, raport o błędach)

Nie wiem, co robić. Myślę, że potrzebuję przewodnika dla nowicjuszy w stylu „Witaj, świecie!”, najlepiej w formie wideo. Dobrze byłoby także mieć wygodne wprowadzenie do HaikuPorter, tak jak zrobiono w GNU hello.

Czytam dalej:

haikuporter to narzędzie do tworzenia ogólnych projektów pakietów dla Haiku. Używa repozytorium HaikuPorts jako bazy dla wszystkich pakietów. Do tworzenia pakietów stosowane są przepisy haikuporter.

Dodatkowo dowiaduję się, że:

Nie ma potrzeby przechowywania przepisów w repozytorium HaikuPorts. Można stworzyć jeszcze jedno repozytorium, umieścić w nim przepisy, a następnie wskazać haikuporter na nie.

Dokładnie to, czego potrzebuję — o ile nie szukam sposobu na publiczne udostępnienie pakietu. Ale to temat na inny post.

Instalacja haikuporter 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/ # spraw, aby było uruchamiane z dowolnego miejsca
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 to demo aplikacja QtQuick do testowania przenoszenia i pakowania Haiku"
HOMEPAGE="https://github.com/probonopd/QtQuickApp"
COPYRIGHT="Brak"
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
}

Budowanie przepisu

Zapisuję plik jako QtQuickApp-1.0.recipe, a następnie uruchamiam haikuporter -S ./QuickApp-1.0.recipe. Sprawdzam zależności dla wszystkich pakietów w repozytorium haikuports, co zajmuje trochę czasu. Idę się napić kawy.

A dlaczego ta kontrola ma być przeprowadzana na moim lokalnym komputerze, a nie centralnie na serwerze raz dla wszystkich?

Według pana waddlesplasha:

Bo można zmieniać dowolny plik w repozytorium 😉 Można to trochę zoptymalizować, obliczając potrzebne informacje wtedy, gdy są potrzebne, ponieważ ostatnie wprowadzone zmiany są dość rzadkie.

~/QtQuickApp> haikuporter QtQuickApp-1.0.recipe
Sprawdzanie, czy jakiekolwiek informacje o zależnościach wymagają aktualizacji ...
Szukam nieaktualnych informacji o zależnościach ...
Błąd: QtQuickApp nie znaleziono w repozytorium

Okazuje się, że nie ma zwykłego pliku przepisu, który zawierałby kod źródłowy twojej aplikacji. Musi być on przechowywany w repozytorium w formacie HaikuPorts.

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

Ten fakt sprawia, że kompilacja jest mniej poręczna. Nie bardzo mi się to podoba, ale myślę, że jest to potrzebne, aby w końcu całe oprogramowanie z otwartym źródłem pojawiło się w HaikuPorts.

Otrzymuję następujące:

> haikuporter -S QtQuickApp-1.0.recipe
Sprawdzanie, czy jakiekolwiek informacje o zależnościach muszą zostać zaktualizowane ...
        aktualizacja informacji o zależnościach QtQuickApp-1.0
Szukam przestarzałych informacji o zależnościach ...
Błąd: QtQuickApp-1.0.recipe nie znaleziono w drzewie.

Co jest nie tak? Po przeczytaniu irc robię:

> haikuporter -S QtQuickApp
Sprawdzanie, czy jakiekolwiek informacje o zależnościach muszą zostać zaktualizowane ...
        aktualizacja informacji o zależnościach QtQuickApp-1.0
Szukam przestarzałych informacji o zależnościach ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Pobieranie: https://github.com/probonopd/QtQuickApp.git ...
--2019-07-14 16:12:44--  https://github.com/probonopd/QtQuickApp.git
Rozwiązywanie github.com... 140.82.118.3
Łączenie z github.com|140.82.118.3|:443... połączono.
HTTP wysyłanie żądania, oczekiwanie na odpowiedź... 301 Przeniesiono na stałe
Lokalizacja: https://github.com/probonopd/QtQuickApp [podążam za]
--2019-07-14 16:12:45--  https://github.com/probonopd/QtQuickApp
Ponowne użycie istniejącego połączenia z github.com:443.
HTTP wysyłanie żądania, oczekiwanie na odpowiedź... 200 OK
Długość: niesprecyzowana [text/html]
Zapis do: ‘/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’ zapisano [90094]
Weryfikacja sumy kontrolnej QtQuickApp.git
Ostrzeżenie: ----- SZABLON SUMY KONTROLNEJ -----
Ostrzeżenie: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"
Ostrzeżenie: -----------------------------
Błąd: Nie znaleziono sumy kontrolnej w przepisie!

Pojawiło się ciekawe pytanie. Jeśli dodam sumę kontrolną do przepisu — czy będzie ona odpowiadać ostatniemu commi git dla ciągłej integracji? (Programista potwierdza: „Nic się nie uda. Przepisy zostały zaprojektowane tak, aby były względnie stabilne”).

Dla żartu dodają do przepisu:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Wciąż to nie zadowala:

> haikuporter -S QtQuickApp
Sprawdzanie, czy jakiekolwiek informacje o zależnościach muszą zostać zaktualizowane ...
        aktualizacja informacji o zależnościach QtQuickApp-1.0
Szukam przestarzałych informacji o zależnościach ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------
Pomijanie pobierania źródła dla QtQuickApp.git
Weryfikacja sumy kontrolnej QtQuickApp.git
Rozpakowywanie źródła QtQuickApp.git
Błąd: Nieuznawany typ archiwum w pliku /boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git

Czemu tak? To jest repozytorium git, kod już tam jest bezpośrednio, nie ma co rozpakowywać. Moim zdaniem narzędzie powinno być wystarczająco inteligentne, aby nie szukać rozpakowacza, jeśli otrzymuje url z GitHub.

Może zadziała uri git://

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

Teraz narzeka tak:

Pobieranie: git://github.com/probonopd/QtQuickApp.git ...
Błąd: Pobieranie z niebezpiecznych źródeł jest wyłączone w haikuports.conf!

Hmm, dlaczego wszystko jest takie skomplikowane, czemu nie można po prostu «pracować»? W końcu dość często można coś zbudować z GitHub. W przeciwieństwie do tego narzędzia, które działa od razu, bez potrzeby konfiguracji, czy jak ja to nazywam «majsterkowania».

Może to zadziała w ten sposób:

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

Nie, nadal dostaję ten durny błąd i robię, jak opisano tutaj

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

Zaczynam przechodzić dalej, ale czemu mnie atakuje (GitHub nie jest bezpieczny!) i nadal próbuje coś rozpakować.

Zgodnie z mr. waddlesplash:

Tak, przyczyną jest chęć sprawdzenia integralności danych pobranych do kompilacji. Jednym z rozwiązań jest weryfikacja sumy kontrolnej archiwum, ale można także haszować pojedyncze pliki, co nie zostanie zrealizowane, ponieważ zajmuje to znacznie więcej czasu. To właśnie skutkuje «niebezpieczeństwem» gita i innych systemów VCS. Prawdopodobnie tak będzie zawsze, ponieważ stworzenie archiwum na GitHubie jest wystarczająco łatwe i często szybsze. W przyszłości być może komunikat o błędzie nie będzie tak krzykliwy… (nie przeprowadzamy już scalania takich przepisów w HaikuPorts).

~QtQuickApp> haikuporter -S QtQuickApp
Sprawdzanie, czy jakiekolwiek informacje o zależnościach muszą być zaktualizowane ...
Szukam nieaktualnych informacji o zależnościach ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Pobieranie: git+https://github.com/probonopd/QtQuickApp.git ...
Ostrzeżenie: NIEBEZPIECZNE ŹRÓDŁA SĄ ZŁE I NIE POWINNY BYĆ UŻYWANE W PRODUKCJI
Ostrzeżenie: PROSZĘ PRZENIEŚĆ DO STATYCZNEGO POBIERANIA ARCHIWUM Z SUMĄ KONTROLNĄ ASAP!
Klonowanie do pustego repozytorium '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
Rozpakowywanie źródła QtQuickApp.git
tar: /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0: Nie można otworzyć: Nie ma takiego pliku ani katalogu
tar: Błąd nie do naprawienia: kończy teraz
Polecenie 'git archive HEAD | tar -x -C "/boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0"' zwróciło kod wyjścia 2

Z przyzwyczajenia idę zapytać dobrych ludzi na kanale #haiku w sieci irc.freenode.net. I co ja bez nich? Po podpowiedzi zrozumiałem, że trzeba używać:

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

Dobrze, teraz jasno widzę, co to robi — pobiera archiwum z kodem źródłowym określonej rewizji. Głupio, z mojego punktu widzenia, i nie do końca to, czego chciałem, a konkretnie — pobrać najnowszą rewizję z gałęzi głównej.

Jeden z deweloperów tak to wyjaśnił:

Mamy własny CI, więc wszystko, co znajduje się w repozytorium haikuports, zostanie spakowane dla wszystkich użytkowników, a nie chcemy ryzykować kompilacją i dostarczaniem 'wszystkiego najnowszego w upstream'.

Rozumiem! Tak czy inaczej, wyszło coś takiego:

czekam na aktywację pakietu budowy QtQuickApp-1.0-1
czekam na aktywację pakietu budowy QtQuickApp-1.0-1
czekam na aktywację pakietu budowy QtQuickApp-1.0-1
czekam na aktywację pakietu budowy QtQuickApp-1.0-1
czekam na aktywację pakietu budowy QtQuickApp-1.0-1
(...)

Powtarza się w ten sposób w nieskończoność. Wygląda na to, że to błąd (jest zgłoszenie? nie znalazłem).

Z haikuporter a repozytorium haikuports Nie odczuwam poziomu 'po prostu działa', ale jako deweloper, podobają mi się niektóre rzeczy w pracy z Haiku. Przez większość czasu przypomina to Open Build Service - zestaw narzędzi do budowy pakietów Linux: niezwykle potężny, z systematycznym podejściem, ale nadmierny dla mojej małej aplikacji typu 'hello world'.

Ponownie, zgodnie z mr. waddlesplash:

Rzeczywiście, HaikuPorter jest dość surowy domyślnie (plus istnieją tryby lint oraz tryb surowy, które czynią go jeszcze surowszym!), ale tylko dlatego, że tworzy pakiety, które będą działać, a nie po prostu tworzyć pakiety. Dlatego zgłasza problemy z niezgłoszonymi zależnościami, niewłaściwie importowanymi bibliotekami, błędnymi wersjami itp. Celem jest wychwycenie wszystkich problemów, w tym przyszłych, zanim użytkownik się o nich dowie (dlatego nie udało się zainstalować avrdude, ponieważ w przepisie w rzeczywistości była wskazana zależność). Biblioteki nie są po prostu oddzielnymi pakietami, a nawet nie określonymi wersjami SO. HaikuPorter śledzi przestrzeganie tego wszystkiego w samych przepisach, aby uniknąć błędów podczas wykonywania.

W zasadzie taki poziom surowości jest uzasadniony przy tworzeniu systemu operacyjnego, ale wydaje mi się zbyteczny dla aplikacji 'hello world'. Postanowiłem spróbować czegoś innego.

Budowanie aplikacji w formacie hpkg, używając polecenia 'package create'

Może ten prosta instrukcja będzie dla mnie lepsza?

mkdir -p apps/
cp QtQuickApp apps/cat >  .PackageInfo <<EOF
name QtQuickApp
version 1.0-1
architecture x86_64

summary "Demo aplikacja QtQuick"
description "QtQuickApp to demo aplikacja QtQuick do testowania portowania i pakowania 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# Zobacz poniżej, jeśli chcesz, aby aplikacja
# również pojawiła się w menu

Niespodziewanie szybko, niespodziewanie prosto, niespodziewanie skutecznie. Dokładnie tak, jak lubię, oszałamiająco!

Instalacja — co i gdzie?

Przeniosłem plik QtQuickApp.hpkg do ⁓/config/packages, używając menedżera plików, po czym QtQuickApp magicznie pojawił się w ⁓/config/apps.
Znowu niespodziewanie szybko, prosto i skutecznie. Oszałamiająco, niesamowicie!

Ale… (jak bez nich!)

Aplikacja wciąż nie pojawia się na liście menu aplikacji ani w QuickLaunch. Myślę, że już wiem, jak to naprawić. W menedżerze plików przenoszę QtQuickApp.hpkg z ⁓/config/packages do /system/packages.

Nie, wciąż nie ma. Wygląda na to, że coś przeoczyłem (no, i instrukcja też).

Przeglądając zakładkę „Zawartość” w HaikuDepot dla niektórych innych aplikacji zauważyłem, że są pliki rodzaju /data/mimedb/application/x-vnd... co więcej, /data/deskbar/menu/Applications/….

Cóż, co powinienem tam umieścić? Hm...

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

Jestem prawie pewien, że ten trik zadziała, ale pozostają pytania: po co to potrzebne, dlaczego to potrzebne? Moim zdaniem psuje to ogólne wrażenie, że system jest bardzo wyrafinowany.

Jak wyjaśnił mr. waddlesplash:

Czasami są aplikacje, które są potrzebne innym aplikacjom, ale nie w menu. Na przykład LegacyPackageInstaller na Twoim zrzucie ekranu, obsługujący archiwa .pkg w formacie BeOS. Chciałbym, aby użytkownicy je instalowali, ale ich obecność w menu spowoduje zamieszanie.

Mam wrażenie, że jest prostsze rozwiązanie, na przykład Hidden=true w plikach .desktop na Linuxie. Czemu nie uczynić „ukrytej” informacji zasobem i atrybutem systemu plików?

Co jest szczególnie niewyrafinowane — nazwa (niejakiej) aplikacji, która pokazuje menu, deskbar, jest sztywno powiązana z ścieżką.

mr. waddlesplash wyjaśnia w tej sprawie:

„Deskbar” w tym przypadku należy rozumieć jako pewien ogólny termin (podobnie jak „taskbar”, odnoszący się zarówno do aplikacji Windows, jak i do ogólnej koncepcji). A ponieważ to deskbar, a nie „Deskbar”, można to również rozumieć w podobny sposób.

2 „prawie identyczne” katalogi z aplikacjami

Dlaczego są 2 katalogi z aplikacjami, a także dlaczego w jednym mój QtQuickApplication jest, a w drugim go nie ma? (To nie jest jeden systemowy, a drugi użytkowy, co osobiście byłoby dla mnie zrozumiałe).
Naprawdę się pogubiłem i myślę, że trzeba by to ujednolicić.

komentarz mr. waddlesplash

W katalogu Aplikacje znajdują się aplikacje, które nie są potrzebne w menu. Jednak sytuację z menu naprawdę należy poprawić, aby uczynić je bardziej konfigurowalnym.

Zgłoszenie, albo się to nie wydarzy 😉

Zastanawiałem się: czy naprawdę potrzebne jest umieszczanie aplikacji w /system/apps, jeśli użytkownik nie chce ich tam widzieć? Może lepiej umieścić je w innym miejscu, gdzie użytkownik nie będzie na nie natrafiał? Tak jak zrobiono to w Mac OS X, gdzie zawartość pakietów .app, która nie powinna być widoczna dla użytkownika w /Applications, ukryta jest w głębi /System/Library/...„.

Co z zależnościami?

Myślę, że warto jakoś wskazać zależności, prawda? Czy można uznać Qt za nieodłączną część domyślnej instalacji Haiku? Nie! Qt nie jest zainstalowane domyślnie. Czy program do budowy pakietów może automatycznie określić zależności, sprawdzając pliki ELF? Powiedziano mi, że HaikuPorter rzeczywiście to robi, a jednak pakiet nie. Wszystko dlatego, że jest po prostu „twórcą pakietów”, który sam w sobie po prostu tworzy pliki. hpkg.

Czy warto uczynić Haiku bardziej wyrafinowanym, dodając politykę, zgodnie z którą pakiet nie powinien mieć zależności od pakietów spoza haikuports? (Мне бы так хотелось, поскольку подобная политика значительно облегчает задачу — система смогла бы автоматически разрешить зависимости каждого пакета, загружаемого откуда угодно, без возни с дополнительными источниками пакетов).

mr. waddlesplash wyjaśnia:

Nie chcielibyśmy ograniczać tak bardzo swobody programistów, bo oczywiste jest, że jeśli FirmaX zechce wspierać swój własny zestaw oprogramowania z zależnościami (a co za tym idzie, również repozytorium) — ma pełną swobodę, aby to zrobić.

W takim przypadku może warto by było zarekomendować unikanie przez zewnętrzne pakiety zależności od czegokolwiek, co nie jest w haikuports, poprzez pełne pakowanie wszystkiego, co potrzebne z aplikacją. Ale myślę, że to temat na przyszły artykuł w tej serii. [Autor sugeruje AppImage? — przyp. tłumacza]

Dodawanie ikony aplikacji

A co jeśli chcę dodać do zasobów mojej nowo stworzonej aplikacji jedną z eleganckich wbudowanych ikon? Okazuje się, że to fascynujący temat, więc stanie się on głównym tematem kolejnego artykułu.

Jak zorganizować ciągłą produkcję aplikacji?

Wyobraź sobie projekt podobny do Inkscape (tak, wiem, że na razie go nie ma w Haiku, ale łatwo to pokazać). Mają oni repozytorium kodu źródłowego. https://gitlab.com/inkscape/inkscape.
Za każdym razem, gdy ktoś zapisuje swoje zmiany w repozytorium, uruchamiane są potoki budowy, po czym poprawki są automatycznie testowane, a aplikacja jest pakowana w różne pakiety, w tym AppImage dla systemu Linux (autonomiczny pakiet aplikacji, który można pobrać do lokalnego testowania niezależnie od tego, co może lub nie może być zainstalowane w systemie. [wiedziałem, że tak będzie! — przyp. tłumacza]). Podobnie dzieje się przy każdym żądaniu scalania gałęzi, więc można pobrać aplikację zbudowaną na podstawie kodu zaproponowanego w żądaniu scalania, zanim nastąpi jego scalanie.

Żądania scalania z statusami budowy oraz możliwością pobrania zbudowanych binarek w przypadku udanej kompilacji (oznaczonej na zielono)

Budowa odbywa się w kontenerach Docker. GitLab oferuje darmowe runnerów na Linuxie, a ja myślę, że można również podłączyć własne runnery (swoją drogą, nie wyobrażam sobie, jak to będzie działać w systemach takich jak Haiku, które, jak wiem, nie mają Dockera ani jego odpowiednika, ale dla FreeBSD również nie ma Dockera, więc ten problem nie jest unikalny dla Haiku).

W idealnym przypadku budowa aplikacji dla Haiku mogłaby być przeprowadzana wewnątrz kontenera Docker dla Linuxa. W takim układzie budowa dla Haiku mogłaby zostać włączona do istniejących potoków. Czy są dostępne kompilatory krzyżowe? A może trzeba emulować całe Haiku wewnątrz kontenera Docker, używając czegoś takiego jak QEMU/KVM (zakładając, że będzie to działać wewnątrz Dockera)? Swoją drogą, wiele projektów stosuje podobne zasady. Na przykład Scribus działa w ten sposób — jest już dostępny dla Haiku. Nastanie dzień, kiedy będę mógł wysyłać takie żądania scalania do innych projektów, aby dodać do nich wsparcie dla Haiku.

Jeden z deweloperów wyjaśnia:

Dla innych projektów, które chcą samodzielnie budować pakiety, obsługiwany jest zwykły sposób CMake/CPack. Inne systemy budowy mogą być wspierane, jeśli wywołają program budowania pakietu bezpośrednio, co jest dobre, jeśli ludzie będą tym zainteresowani. Doświadczenie pokazuje: do tej pory szczególnego zainteresowania nie było, więc haikuporter działał, jak nam pasowało, ale w ostatecznym wyniku oba sposoby powinny działać wspólnie. Powinniśmy przedstawić zestaw narzędzi do krzyżowej budowy oprogramowania z Linuxa lub innego systemu operacyjnego serwerowego (Haiku nie jest przeznaczone do pracy na serwerach).

Brawa na stojąco. Zwykli użytkownicy Linuksa dźwigają cały ten dodatkowy ciężar i dodatkowy bagaż (bezpieczeństwo, ścisła kontrola itp.), który jest potrzebny systemom operacyjnym serwerów, ale nie osobistym. Dlatego całkowicie zgadzam się, że możliwość kompilacji aplikacji dla Haiku na Linuksie to właściwy kierunek.

Podsumowanie

Portowanie aplikacji POSIX na Haiku jest możliwe, ale może wymagać więcej nakładów, niż zwykła rekonfiguracja. Zdecydowanie borykałbym się z tym długo, gdyby nie pomoc ludzi z kanału #haiku w sieci irc.freenode.net. Ale nawet oni nie zawsze od razu dostrzegali, co jest nie tak.

Aplikacje napisane w Qt to łatwe wyjątki. Stworzyłem najprostsze aplikacje demonstracyjne bez większych problemów.

Budowanie pakietów dla prostych aplikacji również jest stosunkowo łatwe, ale tylko dla tych, które "są wydawane w tradycyjny sposób", czyli mają wersjonowane archiwa kodu źródłowego, które mają być wspierane w haikuports. Dla ciągłej kompilacji (kompilacja przy każdej zmianie) z GitHub sytuacja jest już bardziej skomplikowana. Tutaj Haiku bardziej przypomina dystrybucję Linuksa niż wynik na Macu, gdzie można łatwo otrzymać pakiet, klicking na przycisk "Buduj" w XCode. .app, gotowy do wstawienia do obrazu dysku. .dmg, przygotowany do załadowania na mojej stronie.
Ciągła kompilacja aplikacji na bazie "serwerowego" systemu operacyjnego, na przykład Linuksa, prawdopodobnie stanie się możliwa, jeśli będzie popyt ze strony programistów, ale obecnie projekt Haiku ma inne, pilniejsze zadania.

Spróbuj sam! Projekt Haiku udostępnia obrazy do uruchamiania z DVD lub USB, tworzone codziennie. Aby zainstalować, wystarczy pobrać obraz i nagrać go na pendrive'a za pomocą Etcher

Masz pytania? Zapraszamy do naszego rosyjskojęzycznego kanału telegramowego..

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

Od autora tłumaczenia: to piąty artykuł z cyklu o Haiku.

Lista artykułów: Pierwsza Drugi Trzeci Czwarty

Źródło: habr.com