🥇Viides päiväni Haikun kanssa: porttitaan ohjelmia

TL; DR: Aloittelija näki Haikun ensimmäistä kertaa yrittäessään siirtää joitain ohjelmia Linux-maailmasta.

Ensimmäinen Haiku-portoitu ohjelmani, pakattuna hpkg-muotoon

äskettäin Löysin Haikun, yllättävän hyvän käyttöjärjestelmän PC:lle.
Tänään opin siirtämään uusia ohjelmia tähän käyttöjärjestelmään. Pääpaino on kuvaus haikuun siirtymisen ensimmäisestä kokemuksesta Linux-kehittäjän näkökulmasta. Pyydän anteeksi mahdollisia typeriä virheitä, joita tein matkan varrella, sillä ei ole kulunut edes viikkoa siitä, kun latasin Haikun ensimmäisen kerran.

Haluan saavuttaa kolme tavoitetta:

Portti yksinkertainen CLI-sovellus
Siirrä sovellus graafisesta käyttöliittymästä Qt:hen
Pakkaa ne sitten hpkg-muotoon (koska mietin edelleen AppDirin ja AppImagen mukauttamista Haikulle...)

Aloitetaan. Osioissa dokumentointi и suunnittelu, samoin kuin wiki HaikuPortsista löysin oikean suunnan. Netistä löytyy jopa PDF-kirja BeOS: Unix-sovelluksen siirtäminen.
467 sivua - ja tämä on vuodelta 1997! Sisälle katsominen on pelottavaa, mutta toivon parasta. Kehittäjän sanat ovat rohkaisevia: "kesti kauan, koska BeOS ei ollut POSIX-yhteensopiva", mutta Haiku "suurin osa" on jo sellainen.

Yksinkertaisen CLI-sovelluksen siirtäminen

Ensimmäinen ajatus oli siirtää sovellus avrdude, mutta kuten kävi ilmi, tämä on jo ovat tehneet kauan sitten.

Ensimmäinen yritys: ei mitään katsottavaa

Mitä en voi ymmärtää, on se jo Sovelluksia on siirretty Haikulle yli 10 vuoden ajan - huolimatta siitä, että itse käyttöjärjestelmä ei ole vielä edes versio 1.0.

Toinen yritys: täytyy kirjoittaa uudelleen

Joten käytän Ptouch-770, CLI Brother P-Touch 770 -tulostimen ohjaamiseen, jota käytän tarrojen tulostamiseen.
Tulostan siihen erilaisia tarroja, ja olet ehkä nähnyt sen jo edellisessä artikkelissa. Hieman aikaisemmin kirjoitin pienen GUI-kääreohjelman Pythonissa (koska se on Gtk+:ssa, se on kirjoitettava uudelleen, ja tämä on hyvä syy oppia).

Brother P-Touch 770 -tarratulostin Toimiiko se Haikun kanssa?

Haiku-paketinhallinta tietää kirjastoista ja komennoista, joten jos saan "ei löydä libintl" -viestin suorituksen aikana configure - Aloitan juuri pkgman install devel:libintl ja tarvittava paketti löytyy. Samoin pkgman install cmd:rsync. No jne.

Paitsi silloin, kun tämä ei toimi:

/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

Ehkä udev on liian Linux-pohjainen ja siksi sitä ei ole olemassa Haikulle. Tämä tarkoittaa, että minun on muokattava lähdekoodia, jota yritän kääntää.
Eh, et voi hypätä pään yli, enkä edes tiedä mistä aloittaa.

Kolmas yritys

Olisi kiva saada tmate Haikulle, antaisin Haiku-kehittäjien muodostaa yhteyden pääte-istuntooni - jos jokin menee pieleen. Ohjeet ovat melko yksinkertaiset:

./autogen.sh
./configure
make
make install

Näyttää hyvältä, joten mikset kokeilisi sitä Haikulla?

/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

Tässä vaiheessa avaan HaikuDepotin ja haen curses.
Jotain löytyi, mikä antoi vihjeen pätevämpään kyselyyn:

/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

Kävin jälleen HaikuDepotissa ja tietysti löysin devel:msgpack_c_cpp_devel. Mitä nämä oudot nimet ovat?

/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

Tässä vaiheessa ymmärsin, että ohjelman siirtäminen Haikulle vaatii paljon enemmän tietoa kuin mitä yksinkertaiseen uudelleenrakentamiseen tarvitaan.
Puhuin ystävällisten Haiku-kehittäjien kanssa, kävi ilmi, että msgpackissa on virhe, ja muutaman minuutin kuluttua näen HaikuPortsissa korjaustiedoston. Näen omin silmin kuinka korjattu paketti menee tänne (buildslave - virtuaalikoneet).

Korjatun msgpackin rakentaminen buildmasterilla

Välillä lähetän korjaustiedoston ylävirtaan lisätäksesi Haiku-tuen msgpackiin.

Viisi minuuttia myöhemmin päivitetty msgpack on jo saatavilla Haikussa:

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

Odottamattoman hyvä. Sanoinko noin?!

Palaan alkuperäiseen ongelmaan:

/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

Nyt näyttää siltä, että msgpack ei ole viallinen. Minä kommentoin IMAXLABEL в tty.c kuten tämä:

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

Результат:

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, taas mennään... Muuten:

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

Herra. waddlesplish kertoo minne kaivaa:

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

Tässä postasin config.log.

He selittivät minulle, että libresolvissa Haikussa on jotain muutakin. Ilmeisesti koodia on muokattava lisää. Pitää miettiä…

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

Ikuinen kysymys: mitä tapahtuu?

/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

Sama juttu, vain profiilissa. Googletti ja löysi tämän. Jos lisäät -lssp "joskus" auttaa, yritän:

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

Vau! Se alkaa! Mutta…

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

Yritän debugata tiedosto tähän:

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

"Bad port ID" on jo kuin käyntikortti haiku. Ehkä jollain on ideaa mikä on vialla ja miten sen saisi korjattua? Jos on, päivitän artikkelin. Linkki GitHub.

GUI-sovelluksen siirtäminen Qt:hen.

Valitsen yksinkertaisen QML-sovelluksen.

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

Todella yksinkertainen. Vähemmän kuin minuutti!

Sovellusten pakkaus hpkg haikuporterilla ja haikuporteilla.

Mistä minun pitäisi aloittaa? Yksinkertaista dokumentaatiota ei ole, menen #haiku-kanavalle osoitteessa irc.freenode.net ja kuulen:

Joukkue package - matalan tason tapa luoda paketteja. Suurimmaksi osaksi hänelle riittää PackageInfo, kuten kohdassa "Tekeminen oikeaksi .hpkg-paketiksi" on kuvattu.
Minun täytyy tehdä jotain sellainen a
Voi käyttää hpkg-creator (se kaatuu minulle, virheilmoitus)

Ei ole selvää, mitä tehdä. Luulen, että tarvitsen Hello World -tyylisen aloittelijaoppaan, mieluiten videon. Olisi mukava saada myös kätevä johdatus HaikuPorteriin, kuten GNU hellossa tehdään.

Luen seuraavaa:

haikuporter on työkalu yhteisten pakettiprojektien luomiseen Haikulle. Se käyttää HaikuPorts-arkistoa kaikkien pakettien perustana. Haikuporter-reseptejä käytetään pakettien luomiseen.

Lisäksi saan selville, että:

Reseptejä ei tarvitse tallentaa HaikuPortsin tallennustilaan. Voit tehdä toisen arkiston, laittaa reseptit siihen ja sitten osoittaa haikuporterin siihen.

Juuri mitä tarvitsen - jos en etsi tapaa julkaista paketti julkisesti. Mutta tämä on toisen postauksen aihe.

Haikuportterin ja haikuporttien asennus

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

Reseptin kirjoittaminen

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
}

Reseptin kokoaminen

Tallennan tiedoston nimellä QtQuickApp-1.0.recipe, jonka jälkeen käynnistän aikuporter -S ./QuickApp-1.0.recipe. Kaikkien arkiston pakettien riippuvuudet tarkistetaan haikuportit, mikä vie jonkin aikaa. Menen kahville.

Miksi ihmeessä tämä tarkistus pitäisi tehdä paikallisella koneellani eikä keskitetysti palvelimella kerran kaikille?

Mr. waddlespllash:

Sillä, että voit kirjoittaa uudelleen minkä tahansa arkistossa olevan tiedoston 😉 Tätä voi vähän optimoida laskemalla tarvittavat tiedot tarvittaessa, koska viimeksi tehdyt muutokset ovat melko harvinaisia.

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

Osoittautuu, että ei ole olemassa tavallista reseptitiedostoa, joka sisältää sovelluksesi lähdekoodin. Sinun on säilytettävä se HaikuPorts-muodossa olevassa arkistossa.

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

Tämä seikka tekee kokoonpanosta hankalampaa. En pidä siitä erityisen paljon, mutta mielestäni se on välttämätöntä, jotta lopulta kaikki avoimen lähdekoodin ohjelmistot ilmestyvät HaikuPortseihin.

Saan seuraavan:

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

Mikä hätänä? Irc:n lukemisen jälkeen teen:

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

Mielenkiintoinen kysymys heräsi. Jos lisään reseptiin tarkistussumman - vastaako se uusinta git-sitoumusta jatkuvaa integrointia varten? (Kehittäjä vahvistaa: "Se ei toimi. Reseptit on suunniteltu suhteellisen vakaiksi.")

Lisää reseptiin huvin vuoksi:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Ei vieläkään tyytyväinen:

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

Mitä hän tekee? Loppujen lopuksi tämä on git-arkisto, koodi on jo siellä suoraan, ei ole mitään purettavaa. Minun näkökulmastani työkalun pitäisi olla tarpeeksi älykäs, jotta se ei etsi pakkaajaa, jos se on GitHub-URL-osoitteen yläpuolella.

Ehkä uri git:// toimii

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

Nyt se valittaa näin:

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

Hmm, miksi kaikki on niin monimutkaista, miksi et voi "vain työskennellä"? Loppujen lopuksi ei ole harvinaista rakentaa jotain GitHubista. Olipa kyseessä työkalut, jotka toimivat heti, ilman asennusta, tai kuten minä sitä kutsun "huijaukseksi".

Ehkä se toimii näin:

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

Ei. Saan edelleen tämän oudon virheen ja kuten tässä on kuvattu

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

Siirryn hieman pidemmälle, mutta miksi se huutaa minulle (GitHub ei ole suojattu!) ja yrittää silti purkaa jotain.

Mukaan Herra. waddlesplish:

No, kyllä, syynä oli halu tarkistaa kokoonpanoa varten vastaanotettujen tietojen eheys. Yksi vaihtoehdoista on tarkistaa arkiston tarkistussumma, mutta voit tietysti tiivistää yksittäisiä tiedostoja, joita ei toteuteta, koska kestää paljon kauemmin. Seurauksena tästä on gitin ja muiden VCS:ien "turvattomuus". Näin on todennäköisesti aina, koska arkiston luominen GitHubissa on melko helppoa ja usein nopeampaa. No, ehkä jatkossa virheilmoitus ei ole niin räikeä... (emme enää yhdistä tällaisia reseptejä HaikuPortsissa).

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

Vanhasta tottumuksesta käyn kysymässä hyviltä ihmisiltä irc.freenode.net-verkon #haiku-kanavalla. Ja missä minä olisin ilman niitä? Vihjeen jälkeen tajusin, että minun pitäisi käyttää:

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

Okei, kävi selväksi, mitä se tekee - se lataa arkiston tietyn version lähdekoodilla. Minun näkökulmastani se on typerää, eikä aivan sitä, mitä halusin, nimittäin ladata uusin versio päähaaralta.

Yksi kehittäjistä selitti asian näin:

Meillä on oma CI, joten kaikki, mikä on sijoitettu haikuporttien arkistoon, pakataan kaikille käyttäjille, emmekä halua ottaa riskiä kerätä ja toimittaa "kaiken viimeisimmän version ylävirtaan".

Ymmärsi! Joka tapauksessa näin kävi:

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

Se toistaa tämän loputtomiin. Ilmeisesti tämä on virhe (onko sovellusta? En löytänyt sitä).

С haikuporter ja arkisto haikuportit Siinä ei ole "vain toimii" -tunnetta, mutta kehittäjänä pidän Haikun kanssa työskentelystä joistakin asioista. Suurimmaksi osaksi se on samanlainen kuin Open Build Service, joukko työkaluja Linux-koontiversioiden rakentamiseen: erittäin tehokas, systemaattisella lähestymistavalla, mutta ylivoimainen pienelle "hello world" -sovellukselleni.

Jälleen mr. waddlespllash:

Todellakin, HaikuPorter on oletuksena melko tiukka (lisäksi siinä on nukkatila sekä tiukka tila, jotta se olisi vielä tiukempi!), mutta vain siksi, että se luo toimivia paketteja sen sijaan, että se luo paketteja. Siksi hän valittaa ilmoittamattomista riippuvuuksista, väärin tuoduista kirjastoista, virheellisistä versioista jne. Tavoitteena on saada kiinni kaikista ongelmista, myös tulevista, ennen kuin käyttäjä tietää niistä (tämän vuoksi avrduden asentaminen ei ollut mahdollista, koska riippuvuus oli todella määritelty reseptissä). Kirjastot eivät ole vain yksittäisiä paketteja tai edes tiettyjä SO-versioita. HaikuPorter varmistaa, että tämä kaikki huomioidaan itse resepteissä, jotta vältytään virheiltä suorituksen aikana.

Periaatteessa tämän tasoinen kurinalaisuus on perusteltua käyttöjärjestelmää luotaessa, mutta minusta se tuntuu tarpeettomalta "hello world" -sovellukselle. Päätin kokeilla jotain muuta.

Rakenna sovelluksia hpkg-muodossa "package create" -komennolla

ehkä tämä Toimivatko yksinkertaiset ohjeet paremmin minulle?

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

Odottamattoman nopea, yllättävän yksinkertainen, odottamattoman tehokas. Juuri sellainen kuin minä pidän, mahtavaa!

Asennus - mitä ja missä?

Siirrettiin QtQuickApp.hpkg-tiedosto kohteeseen ~/config/packagestiedostonhallinnan avulla, jonka jälkeen QtQuickApp ilmestyi taianomaisesti sisään ~/config/apps.
Jälleen yllättävän nopea, yksinkertainen ja tehokas. Hämmästyttävää, uskomatonta!

Mutta... (missä me olisimme ilman niitä!)

Sovellus puuttuu edelleen sovellusvalikkoluettelosta ja QuickLaunchista. Luulen jo tietäväni kuinka korjata se. Siirrän tiedostonhallinnassa QtQuickApp.hpkg:n osoitteesta ~/config/packages kansioon /system/packages.

Ei, vielä puuttuu. Ilmeisesti minulta (no, ja ohjeilta) jäi jotain paitsi.

Tarkastellessani HaikuDepotin "Sisältö"-välilehteä joidenkin muiden sovellusten varalta huomasin, että siellä on tiedostoja, kuten /data/mimedb/application/x-vnd... mikä vielä merkillisempää on /data/deskbar/menu/Applications/….

No mitä sinne pitäisi laittaa? Älä viitsi...

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

Olen melko varma, että tämä temppu toimii, mutta kysymykset jäävät: miksi tämä on tarpeen, mihin se on tarkoitettu? Mielestäni tämä pilaa kokonaisvaikutelman, että järjestelmä on niin hienostunut.

Kuten Mr. waddlespllash:

Joskus on sovelluksia, joita muut sovellukset tarvitsevat, mutta jotka eivät ole valikossa. Esimerkiksi kuvakaappauksessasi oleva LegacyPackageInstaller, joka käsittelee .pkg-arkistoja BeOS-muodossa. Haluaisin käyttäjien asentavan ne, mutta heidän läsnäolonsa valikossa aiheuttaa sekaannusta.

Jostain syystä minusta tuntuu, että on olemassa esimerkiksi yksinkertaisempi ratkaisu Hidden=true tiedostoissa .desktop Linuxissa. Miksi ei tehdä "piilotetuista" tiedoista tiedostojärjestelmän resurssi ja attribuutti?

Mikä ei ole erityisen hienovaraista, on (jonkin) sovelluksen nimi, joka näyttää valikon, deskbar, sidottu tiukasti matkan varrella.

Herra. waddlesplash selittää tämän:

"Työpöytäpalkki" tulee tässä tapauksessa ymmärtää eräänlaisena yleisenä terminä (samalla tavalla kuin "tehtäväpalkki", joka viittaa sekä Windows-sovellukseen että yleiseen käsitteeseen). No tästä lähtien deskbar, ei "Deskbar", tämä voidaan myös ymmärtää samalla tavalla.

2 "melkein identtistä" hakemistoa, joissa on sovelluksia

Miksi sovelluksia on kaksi hakemistoa ja miksi QtQuickApplication on toisessa, mutta ei toisessa? (Tämä ei loppujen lopuksi ole yksi järjestelmä, vaan toinen käyttäjä, mikä olisi minulle henkilökohtaisesti ymmärrettävää).
Olen todella hämmentynyt ja mielestäni tämän pitäisi olla yhtenäinen.

kommentin kirjoittaja mr. waddlesplish

Sovellusluettelo sisältää sovelluksia, joita ei tarvita valikossa. Mutta ruokalistan tilannetta on todellakin parannettava, jotta se olisi räätälöitävämpi.

Hakemus, tai se ei tapahdu 😉

Mietin: onko todella tarpeen isännöidä sovelluksia /system/apps, jos käyttäjät näkevät ne siellä, se ei ole toivottavaa. Ehkä olisi parempi sijoittaa ne toiseen paikkaan, jossa käyttäjä ei kohtaa niitä? Aivan kuten se tehdään Mac OS X:ssä, jossa pakettien sisältö .app, jonka ei pitäisi näkyä käyttäjälle /Applications, piiloutuen /System/Library/…"`:n syvyyksiin.

Entä riippuvuudet?

Mielestäni kannattaa jotenkin määritellä riippuvuudet, eikö? Voidaanko Qt:tä pitää oletuksena pakollisena osana Haiku-asennusta? Ei! Qt:tä ei ole asennettu oletusarvoisesti. Voiko paketin rakentaja tunnistaa riippuvuudet automaattisesti tarkistamalla ELF-tiedostot? Minulle kerrottiin, että HaikuPorter todella tekee tämän, mutta package Ei. Tämä johtuu siitä, että se on vain "pakettien rakentaja", joka vain luo tiedostoja itse hpkg.

Pitäisikö Haikuista tehdä kehittyneempiä lisäämällä käytäntö, jonka mukaan paketti ei saa olla riippuvainen Haikun ulkopuolisista paketeista? haikuports? (Haluaisin, koska tällainen käytäntö tekisi asioista paljon helpompaa - järjestelmä pystyisi automaattisesti ratkaisemaan jokaisen mistä tahansa ladatun paketin riippuvuudet ilman, että joutuisi sotkemaan muita pakettilähteitä.)

Herra. waddlesplash selittää:

Emme haluaisi niin paljon rajoittaa kehittäjien vapautta, koska on selvää, että jos CompanyX haluaa tukea omaa ohjelmistojoukkoaan riippuvuuksilla (ja siten arkistolla), se tekee sen täysin vapaasti.

Siinä tapauksessa saattaa olla syytä suositella, että kolmannen osapuolen paketit välttävät riippuvuuksia muusta kuin haikuporteista pakkaamalla kaikki tarvittava kokonaan sovelluksen mukana. Mutta mielestäni tämä on tämän sarjan tulevan artikkelin aihe. [Onko kirjoittaja matkalla kohti AppImagea? - n. kääntäjä]

Sovelluskuvakkeen lisääminen

Entä jos haluan lisätä yhden siisteistä sisäänrakennetuista kuvakkeista juuri luodun sovellukseni resursseihin? Osoittautuu, että tämä on hämmästyttävä aihe, joten se on seuraavan artikkelin perusta.

Kuinka järjestää jatkuvat sovellusrakenteet?

Kuvittele Inkscapen kaltainen projekti (kyllä, tiedän, että se ei ole vielä saatavilla Haikussa, mutta se on kätevä näyttää siinä). Heillä on lähdekoodivarasto https://gitlab.com/inkscape/inkscape.
Joka kerta kun joku tekee muutokset arkistoon, käynnistetään koontiputkistot, minkä jälkeen muutokset testataan, rakennetaan ja sovellus pakataan automaattisesti erilaisiin paketteihin, mukaan lukien AppImage for Linux (erillinen sovelluspaketti, joka voidaan ladata paikallista testausta varten riippumatta mitä järjestelmään voidaan asentaa tai ei [Tiesin sen! - n. kääntäjä]). Sama tapahtuu jokaisessa haaran yhdistämispyynnössä, joten voit ladata yhdistämispyynnössä ehdotetusta koodista rakennetun sovelluksen ennen yhdistämistä.

Yhdistä pyynnöt koontitiloilla ja mahdollisuudella ladata käännetyt binaarit, jos koonti on onnistunut (merkitty vihreällä)

Rakennus toimii Docker-säiliöissä. GitLab tarjoaa ilmaisia juoksijoita Linuxissa, ja mielestäni voisi olla mahdollista sisällyttää omat juoksijasi (muuten, en muuten ymmärrä, miten tämä toimisi Haiku-kaltaisissa järjestelmissä, joissa tiedän, ettei niissä ole Dockeria tai vastaavaa, mutta Myöskään FreeBSD:lle ei ole Dockeria, joten tämä ongelma ei ole ainutlaatuinen Haikulle).

Ihannetapauksessa Haiku-sovellukset voidaan rakentaa Docker-säilön sisään Linuxille. Tässä tilanteessa Haiku-kokoonpano voidaan viedä olemassa oleviin putkiin. Onko ristikääntäjiä? Vai pitäisikö minun emuloida kaikkia Docker-säiliön sisällä olevia Haikuja käyttämällä jotain QEMU/KVM:ää (olettaen, että se toimii niin Dockerin sisällä)? Muuten, monet hankkeet käyttävät samanlaisia periaatteita. Esimerkiksi Scribus tekee tämän - se on jo saatavilla Haikulle. Eräänä päivänä tulee päivä, jolloin voin lähettää niin Vedä pyyntöjä muihin projekteihin lisätäksesi Haiku-tuen.

Yksi kehittäjistä selittää:

Muissa projekteissa, jotka haluavat luoda paketteja itse, tuetaan tavallista CMake/CPack-menetelmää. Muita koontijärjestelmiä voidaan tukea kutsumalla suoraan paketin koontiohjelmaan, mikä on hyvä, jos ihmiset ovat kiinnostuneita siitä. Kokemus osoittaa: toistaiseksi kiinnostusta ei ole ollut paljoa, joten haikuporter toimi meille sopivasti, mutta loppujen lopuksi molempien menetelmien pitäisi toimia yhdessä. Meidän pitäisi ottaa käyttöön joukko työkaluja Linuxin tai minkä tahansa muun palvelinkäyttöjärjestelmän ohjelmistojen rakentamiseen (Haikua ei ole suunniteltu toimimaan palvelimilla).

Annan seisovat suosionosoitukset. Tavalliset Linux-käyttäjät kantavat mukanaan kaiken tämän lisäkuorman ja lisämatkatavarat (turvallisuus, tiukka valvonta jne.), jotka ovat välttämättömiä palvelimen käyttöjärjestelmälle, mutta ei henkilökohtaiselle. Joten olen täysin samaa mieltä siitä, että Haiku-sovellusten rakentaminen Linuxissa on oikea tapa.

Johtopäätös

POSIX-sovellusten siirtäminen Haikulle on mahdollista, mutta se voi olla kalliimpaa kuin tyypillinen uudelleenrakentaminen. Olisin varmasti jumissa tämän kanssa pitkään, ellei irc.freenode.net-verkon #haiku-kanavan ihmisiä olisi apua. Mutta hekään eivät aina heti nähneet, mikä oli vialla.

Qt:llä kirjoitetut sovellukset ovat helppo poikkeus. Tein yksinkertaisen esittelysovelluksen ilman ongelmia.

Paketin rakentaminen yksinkertaisiin sovelluksiin on myös melko helppoa, mutta vain "perinteisesti julkaistuille", ts. jolla on versioidut lähdekoodiarkistot, jotka on tarkoitettu haikuporttien tukemiseen. Jatkuvassa rakentamisessa (koonti jokaista muutossitoumusta varten) GitHubin kanssa kaikki ei näytä olevan niin yksinkertaista. Tässä Haiku tuntuu enemmän Linux-jakelulta kuin tulokselta Macissa, jossa kun napsautat "Build"-painiketta XCodessa, saat paketin .app, valmiina lisättäväksi levykuvaan .dmg, valmis ladattavaksi verkkosivustolleni.
Jatkuva "palvelin"-käyttöjärjestelmään, esimerkiksi Linuxiin, perustuvien sovellusten rakentaminen tulee todennäköisesti mahdolliseksi, jos kehittäjiltä on kysyntää, mutta tällä hetkellä Haiku-projektilla on muita, painavampia tehtäviä.

Kokeile itse! Loppujen lopuksi Haiku-projekti tarjoaa kuvia käynnistettäväksi DVD- tai USB-levyltä päivittäin. Asentaaksesi lataa vain kuva ja kirjoita se flash-asemaan käyttämällä etsaaja

Onko sinulla kysymyksiä? Kutsumme sinut venäjänkieliseen sähke kanava.

Virheiden yleiskatsaus: Kuinka ampua itseäsi jalkaan C:ssä ja C++:ssa. Kokoelma Haiku OS -reseptejä

Alkaen kirjailija käännös: tämä on viides artikkeli Haikua käsittelevässä sarjassa.

Luettelo artikkeleista: Ensimmäinen Toinen Kolmas neljäs

Lähde: will.com

Viides päiväni Haikun kanssa: laitetaan ohjelmaa