ჩემი მეხუთე დღე ჰაიკუსთან ერთად: მოდით გადავიტანოთ რამდენიმე პროგრამა

TL; DR: ახალმა ადამიანმა პირველად დაინახა ჰაიკუ, რომელიც ცდილობდა ლინუქსის სამყაროდან რამდენიმე პროგრამის პორტირებას.

ჩემი პირველი Haiku პორტირებული პროგრამა, შეფუთული მისი hpkg ფორმატში

ცოტა ხნის წინ მე აღმოვაჩინე Haiku, საოცრად კარგი ოპერაციული სისტემა კომპიუტერებისთვის.
დღეს მე ვისწავლი ახალი პროგრამების პორტირებას ამ ოპერაციულ სისტემაში. მთავარი აქცენტი არის ჰაიკუზე გადასვლის პირველი გამოცდილების აღწერა Linux-ის დეველოპერის თვალსაზრისით. ბოდიშს ვიხდი ყველა სულელური შეცდომისთვის, რაც გზაში დავუშვი, რადგან ერთი კვირაც არ არის გასული მას შემდეგ, რაც პირველად გადმოვწერე ჰაიკუ.

სამი მიზნის მიღწევა მინდა:

• მარტივი CLI აპლიკაციის პორტირება
• გადაიტანეთ აპლიკაცია GUI-დან Qt-ზე
• შემდეგ შეფუთეთ ისინი hpkg ფორმატში (რადგან ჯერ კიდევ ვფიქრობ Haiku-სთვის AppDir-ისა და AppImage-ის ადაპტაციაზე...)

Დავიწყოთ. სექციებში დოკუმენტაცია и განვითარება, ისევე, როგორც ვიკი HaikuPorts-დან ვიპოვე სწორი მიმართულება. არსებობს ონლაინ PDF წიგნიც კი BeOS: Unix აპლიკაციის პორტირება.
467 გვერდი - და ეს არის 1997 წლიდან! საშინელებაა შიგნით შეხედვა, მაგრამ საუკეთესოს იმედი მაქვს. დეველოპერის სიტყვები გამამხნევებელია: „დიდი დრო დასჭირდა, რადგან BeOS არ იყო POSIX-თან თავსებადი“, მაგრამ Haiku „უმეტესწილად“ უკვე ასეა.

მარტივი CLI აპლიკაციის პორტირება

პირველი აზრი იყო აპლიკაციის პორტირება ავდრუდე, მაგრამ, როგორც აღმოჩნდა, ეს უკვე არის გააკეთეს დიდი ხნის წინ.

პირველი სცადეთ: საყურებელი არაფერია

რასაც ვერ ვხვდები უკვე აპლიკაციები პორტირებულია ჰაიკუზე 10 წელზე მეტი ხნის განმავლობაში - მიუხედავად იმისა, რომ თავად OS ჯერ კიდევ არ არის ვერსია 1.0.

მეორე მცდელობა: საჭიროა გადაწერა

ამიტომ გამოვიყენებ პტოჩ-770, CLI Brother P-Touch 770 პრინტერის სამართავად, რომელსაც ვიყენებ ეტიკეტების დასაბეჭდად.
მე ვბეჭდავ მასზე სხვადასხვა ეტიკეტებს და შეიძლება უკვე გქონდეთ ნანახი წინა სტატიაში. ცოტა ადრე დავწერე პატარა GUI wrapper პროგრამა Python-ში (რადგან ის Gtk+-შია, ხელახლა უნდა დაიწეროს და ეს კარგი მიზეზია სწავლისთვის).

Brother P-Touch 770 ეტიკეტის პრინტერი. იმუშავებს თუ არა ჰაიკუსთან?

Haiku-ს პაკეტის მენეჯერმა იცის ბიბლიოთეკებისა და ბრძანებების შესახებ, ასე რომ, თუ გაშვებისას მივიღებ შეტყობინებას „ვერ ვიპოვე libintl“ configure - ახლახან გავუშვი pkgman install devel:libintl და მოიძებნება საჭირო პაკეტი. ანალოგიურად pkgman install cmd:rsync. ისე და ა.შ.

გარდა იმ შემთხვევებისა, როდესაც ეს არ მუშაობს:

/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

შესაძლოა, udev ზედმეტად დაფუძნებული Linux-ზეა და ამიტომ არ არსებობს ჰაიკუსთვის. რაც ნიშნავს, რომ მე უნდა შევცვალო კოდი, რომლის შედგენასაც ვცდილობ.
ეჰ, შენ თავზე ვერ გადახტები და არც კი ვიცი საიდან დავიწყო.

მესამე ცდა

კარგი იქნებოდა tmate ჰაიკუსთვის, მაშინ მე მივცემ უფლებას ჰაიკუს დეველოპერებს დაუკავშირდნენ ჩემს ტერმინალის სესიას - თუ რამე არასწორედ მოხდება. ინსტრუქციები საკმაოდ მარტივია:

./autogen.sh
./configure
make
make install

კარგად გამოიყურება, რატომ არ სცადოთ ის ჰაიკუზე?

/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

ამ ეტაპზე მე ვხსნი HaikuDepot და ვეძებ curses.
ნაპოვნია რაღაც, რამაც მინიშნება მომცა უფრო კომპეტენტური შეკითხვისთვის:

/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

ისევ მივედი HaikuDepot-ში და, რა თქმა უნდა, ვიპოვე devel:msgpack_c_cpp_devel. რა არის ეს უცნაური სახელები?

/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

ამ საფეხურზე მივხვდი, რომ პროგრამის პორტირება ჰაიკუზე გაცილებით მეტ ცოდნას მოითხოვს, ვიდრე საჭიროა მარტივი აღდგენისთვის.
მე ველაპარაკე Haiku-ს მეგობრულ დეველოპერებს, თურმე არის შეცდომა msgpack-ში და რამდენიმე წუთის შემდეგ ვხედავ პატჩს HaikuPorts-ში. მე ჩემი თვალით ვხედავ როგორ შესწორებული პაკეტი მიდის აქ (buildslave - ვირტუალური მანქანები).

შესწორებული msgpack-ის აგება buildmaster-ზე

შუალედებში მე ვაგზავნი პაჩს ზემოთ დინებაში რომ დაამატოთ Haiku მხარდაჭერა msgpack-ში.

ხუთი წუთის შემდეგ, განახლებული msgpack უკვე ხელმისაწვდომია ჰაიკუში:

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

მოულოდნელად კარგი. მე ვთქვი ეს?!

ვუბრუნდები საწყის პრობლემას:

/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

ახლა, როგორც ჩანს, msgpack არ არის დამნაშავე. კომენტარს ვაკეთებ IMAXLABEL в tty.c ასე:

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.

აბა, ისევ მივდივართ... სხვათა შორის:

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

ბატონი. ჭექა-ქუხილი გეუბნებათ სად გათხრა:

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

აი დავპოსტავ config.log.

მათ ამიხსნეს, რომ ჰაიკუზე libresolv-ის გარდა, ლიბნეთურქში კიდევ არის რაღაც. როგორც ჩანს, კოდის შემდგომი რედაქტირებაა საჭირო. საჭიროა დაფიქრება…

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

მარადიული კითხვა: რა ხდება?

/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

იგივე, მხოლოდ პროფილში. Googleed და იპოვა ეს. თუ დაამატებ -lssp "ზოგჯერ" მეხმარება, ვცდილობ:

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

Ვაუ! იწყება! მაგრამ…

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

ვეცდები გამართვა ფაილი აქ:

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

„ცუდი პორტის ID“ უკვე სავიზიტო ბარათს ჰგავს ჰაიკუ. იქნებ ვინმეს ჰქონდეს წარმოდგენა რისი ბრალია და როგორ გამოვასწორო? თუ ასეა, განვაახლებ სტატიას. Ბმული GitHub.

GUI აპლიკაციის პორტირება Qt.

მე ვირჩევ მარტივ 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!

მართლაც მარტივი. Წუთზე ნაკლები!

აპლიკაციების შეფუთვა hpkg-ში haikuporter-ისა და haikuports-ის გამოყენებით.

რითი დავიწყო? მარტივი დოკუმენტაცია არ არსებობს, მივდივარ #haiku არხზე irc.freenode.net-ზე და მესმის:

• გუნდი package - პაკეტების შექმნის დაბალი დონის გზა. უმეტესწილად, მისთვის საკმარისია PackageInfo, როგორც ეს აღწერილია განყოფილებაში "გადაქცევა .hpkg შესაბამის პაკეტში"
• რაღაც უნდა გავაკეთო არის
• შეგიძლიათ გამოიყენოთ hpkg-შემქმნელი (ჩემთვის ავარია, შეცდომის მოხსენება)

გაუგებარია რა უნდა გააკეთოს. ვფიქრობ, მჭირდება Hello World სტილის დამწყებთათვის სახელმძღვანელო, იდეალურად ვიდეო. კარგი იქნებოდა HaikuPorter-ის მოსახერხებელი შესავალიც გვქონდეს, როგორც ეს კეთდება GNU hello-ში.

წავიკითხე შემდეგი:

haikuporter არის ინსტრუმენტი ჰაიკუსთვის საერთო პაკეტის პროექტების შესაქმნელად. ის იყენებს HaikuPorts საცავს, როგორც საფუძველს ყველა პაკეტისთვის. Haikuporter რეცეპტები გამოიყენება პაკეტების შესაქმნელად.

გარდა ამისა, მე ვხვდები, რომ:

არ არის საჭირო რეცეპტების შენახვა HaikuPorts-ის საცავში. შეგიძლიათ გააკეთოთ სხვა საცავი, ჩადოთ მასში რეცეპტები და შემდეგ მიუთითოთ მასზე haikuporter.

მხოლოდ ის, რაც მე მჭირდება - თუ არ ვეძებ საშუალება საჯაროდ გამოვაქვეყნო პაკეტი. მაგრამ ეს სხვა პოსტის თემაა.

haikuporter და 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

რეცეპტის დაწერა

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
}

რეცეპტის აწყობა

მე ვინახავ ფაილს სახელის ქვეშ QtQuickApp-1.0.recipe, რის შემდეგაც გავუშვი aikuporter -S ./QuickApp-1.0.recipe. დამოკიდებულებები შემოწმებულია საცავში არსებული ყველა პაკეტისთვის ჰაიკუპორტები, რასაც გარკვეული დრო სჭირდება. წავალ ყავას ვსვავ.

რატომ უნდა მოხდეს ეს შემოწმება ჩემს ადგილობრივ აპარატზე და არა ცენტრალიზებულად სერვერზე ერთხელ ყველასთვის?

ბ-ნ. waddlesplash:

იმით, რომ თქვენ შეგიძლიათ გადაწეროთ ნებისმიერი ფაილი საცავში 😉 შეგიძლიათ ამის მცირედი ოპტიმიზაცია, საჭიროების შემთხვევაში საჭირო ინფორმაციის გამოთვლა, რადგან ბოლო ცვლილებები საკმაოდ იშვიათია.

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

გამოდის, რომ არ არსებობს ჩვეულებრივი რეცეპტის ფაილი, რომელიც შეიცავს თქვენი აპლიკაციის წყაროს კოდს. თქვენ უნდა შეინახოთ ის HaikuPorts ფორმატში საცავში.

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

ეს ფაქტი აწყობას უფრო რთულს ხდის. განსაკუთრებით არ მომწონს, მაგრამ ვფიქრობ, რომ აუცილებელია, რათა საბოლოოდ HaikuPorts-ში გამოჩნდეს ყველა ღია კოდის პროგრამა.

მე ვიღებ შემდეგს:

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

Რა მოხდა? irc-ის წაკითხვის შემდეგ ვაკეთებ:

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

საინტერესო კითხვა გაჩნდა. თუ რეცეპტს დავამატე საკონტროლო ჯამი - შეესაბამება თუ არა ის უახლეს git commit-ს უწყვეტი ინტეგრაციისთვის? (დეველოპერი ადასტურებს: "ეს არ იმუშავებს. რეცეპტები შექმნილია შედარებით სტაბილურად.")

გასართობად დაამატეთ რეცეპტს:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

ჯერ კიდევ არ არის კმაყოფილი:

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

Რას აკეთებს? ყოველივე ამის შემდეგ, ეს არის git საცავი, კოდი უკვე არის პირდაპირ, გასახსნელი არაფერია. ჩემი აზრით, ინსტრუმენტი უნდა იყოს საკმარისად ჭკვიანი, რომ არ მოძებნოს გამხსნელი, თუ ის მდებარეობს GitHub url-ის ზემოთ.

ალბათ uri git:// იმუშავებს

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

ახლა ასე ჩივის:

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

ჰმ, რატომ არის ყველაფერი ასე რთული, რატომ არ შეგიძლია "უბრალოდ მუშაობა"? ყოველივე ამის შემდეგ, არც ისე იშვიათია GitHub-დან რაიმეს აშენება. იქნება ეს ინსტრუმენტები, რომლებიც მუშაობენ მაშინვე, დაყენების საჭიროების გარეშე, ან როგორც მე ვუწოდებ "ფუზს".

ალბათ ასე იმუშავებს:

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

არა. მე მაინც ვიღებ ამ უცნაურ შეცდომას და ვაკეთებ, როგორც აქ არის აღწერილი

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

ცოტა წინ მივდივარ, მაგრამ რატომ მიყვირის (GitHub არ არის დაცული!) და მაინც ცდილობს რაღაცის ამოლაგებას.

მიხედვით ბატონი. ჭექა-ქუხილი:

დიახ, დიახ, მიზეზი იყო შეკრებისთვის მიღებული მონაცემების მთლიანობის შემოწმების სურვილი. ერთ-ერთი ვარიანტია არქივის საკონტროლო ჯამის გადამოწმება, მაგრამ, რა თქმა უნდა, შეგიძლიათ ცალკეული ფაილების გაშიშება, რომლებიც არ განხორციელდება, რადგან გაცილებით მეტი დრო სჭირდება. ამის შედეგია git და სხვა VCS-ის „დაუცველობა“. ეს, სავარაუდოდ, ყოველთვის ასე იქნება, რადგან GitHub-ზე არქივის შექმნა საკმაოდ მარტივი და ხშირად უფრო სწრაფია. ჰოდა, მომავალში, ალბათ, შეცდომის შეტყობინება არც ისე მოციმციმე იქნება... (მსგავს რეცეპტებს 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

ძველი ჩვევის გამო მივდივარ კარგ ხალხს ვკითხავ #haiku არხზე irc.freenode.net ქსელში. და სად ვიქნებოდი მათ გარეშე? მინიშნების შემდეგ მივხვდი, რომ უნდა გამომეყენებინა:

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

კარგი, გაირკვა რას აკეთებს - ჩამოტვირთავს არქივს გარკვეული გადასინჯვის წყაროს კოდით. სისულელეა, ჩემი გადმოსახედიდან, და არა ზუსტად ის, რაც მინდოდა, კერძოდ, უახლესი რევიზიის ჩამოტვირთვა სამაგისტრო ფილიალიდან.

ერთ-ერთმა დეველოპერმა ეს ასე ახსნა:

ჩვენ გვაქვს ჩვენი საკუთარი CI, ამიტომ ყველაფერი, რაც განთავსდება haikuports-ის საცავში, შეფუთული იქნება ყველა მომხმარებლისთვის და ჩვენ არ გვინდა რისკის ქვეშ შევაგროვოთ და მივაწოდოთ „ყველაფერი უახლესი ვერსიის ზემოთ“.

გასაგებია! ყოველ შემთხვევაში, ასე მოხდა:

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

ის იმეორებს ამ უსასრულოდ. როგორც ჩანს, ეს შეცდომაა (აპლიკაცია არის? ვერ ვიპოვე).

С haikuporter და საცავი ჰაიკუპორტები მას არ აქვს „უბრალოდ მუშაობს“ შეგრძნება, მაგრამ როგორც დეველოპერს, არის რაღაცეები, რაც მომწონს ჰაიკუსთან მუშაობაში. უმეტესწილად, ის ჰგავს Open Build Service-ს, ინსტრუმენტების კომპლექტს Linux build-ების შესაქმნელად: უკიდურესად ძლიერი, სისტემატური მიდგომით, მაგრამ გადაჭარბებული ჩემი პატარა "hello world" აპლიკაციისთვის.

ისევ, ბატონის თქმით. waddlesplash:

მართლაც, HaikuPorter ნაგულისხმევად საკმაოდ მკაცრია (პლუს, არის ლინტის რეჟიმი და მკაცრი რეჟიმი, რომ ის კიდევ უფრო მკაცრი გახდეს!), მაგრამ მხოლოდ იმიტომ, რომ ის ქმნის პაკეტებს, რომლებიც იმუშავებენ და არა მხოლოდ პაკეტების შექმნას. ამიტომაც უჩივის გამოუცხადებელ დამოკიდებულებებს, არასწორად შემოტანილ ბიბლიოთეკებს, არასწორ ვერსიებს და ა.შ. მიზანია დაიჭიროთ ნებისმიერი და ყველა პრობლემა, მათ შორის მომავალი, სანამ მომხმარებელმა გაიგოს ამის შესახებ (ამიტომაც ვერ მოხერხდა avrdude-ის დაყენება, რადგან დამოკიდებულება რეალურად იყო მითითებული რეცეპტში). ბიბლიოთეკები არ არის მხოლოდ ინდივიდუალური პაკეტები ან თუნდაც კონკრეტული SO ვერსიები. HaikuPorter უზრუნველყოფს, რომ ეს ყველაფერი დაცულია თავად რეცეპტებში, რათა თავიდან იქნას აცილებული შეცდომები შესრულების დროს.

პრინციპში, სიმკაცრის ეს დონე გამართლებულია ოპერაციული სისტემის შექმნისას, მაგრამ არასაჭირო მეჩვენება "hello world" აპლიკაციისთვის. გადავწყვიტე სხვა რამე მეცადა.

აპლიკაციების აგება hpkg ფორმატში "პაკეტის შექმნის" ბრძანების გამოყენებით

Შესაძლოა, ამ მარტივი ინსტრუქციები უკეთესი იქნება ჩემთვის?

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

მოულოდნელად სწრაფი, მოულოდნელად მარტივი, მოულოდნელად ეფექტური. ზუსტად როგორ მომწონს, საოცარი!

ინსტალაცია - რა და სად?

გადაიტანეს QtQuickApp.hpkg ფაილი ~/config/packagesფაილ მენეჯერის გამოყენებით, რის შემდეგაც QtQuickApp ჯადოსნურად გამოჩნდა ~/config/apps.
კიდევ ერთხელ, მოულოდნელად სწრაფი, მარტივი და ეფექტური. საოცარი, წარმოუდგენელი!

მაგრამ... (სად ვიქნებოდით მათ გარეშე!)

აპი ჯერ კიდევ აკლია აპების მენიუს სიიდან და QuickLaunch-ში. მგონი უკვე ვიცი როგორ გამოვასწორო. ფაილ მენეჯერში გადავიტან QtQuickApp.hpkg ~/config/packages-ზე /system/packages-ზე.

არა, მაინც აკლია. როგორც ჩანს, მე (კარგად და ინსტრუქციები) რაღაც გამომრჩა.

სხვა აპლიკაციებისთვის HaikuDepot-ში „შინაარსი“ ჩანართს რომ გადავხედე, დავინახე, რომ არის ისეთი ფაილები, როგორიცაა /data/mimedb/application/x-vnd... რაც კიდევ უფრო საყურადღებოა /data/deskbar/menu/Applications/….

აბა, რა უნდა დავაყენო იქ? Მოდი...

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

დარწმუნებული ვარ, რომ ეს ხრიკი იმუშავებს, მაგრამ კითხვები რჩება: რატომ არის ეს საჭირო, რისთვის არის ეს? ვფიქრობ, ეს ანგრევს საერთო შთაბეჭდილებას, რომ სისტემა ასე დახვეწილია.

როგორც განმარტა ბატონმა. waddlesplash:

ზოგჯერ არის აპლიკაციები, რომლებიც სხვა აპლიკაციებს სჭირდებათ, მაგრამ არ არის მენიუში. მაგალითად, LegacyPackageInstaller თქვენს ეკრანის სურათზე, ამუშავებს .pkg არქივებს BeOS ფორმატში. მინდა მომხმარებლებმა დააინსტალირონ, მაგრამ მენიუში მათი ყოფნა დაბნეულობას გამოიწვევს.

რატომღაც მეჩვენება, რომ არსებობს უფრო მარტივი გამოსავალი, მაგალითად Hidden=true ფაილებში .desktop Linux-ზე. რატომ არ ვაქციოთ „დამალული“ ინფორმაცია ფაილური სისტემის რესურსად და ატრიბუტად?

რაც განსაკუთრებით არ არის დახვეწილი არის (ზოგიერთი) აპლიკაციის სახელი, რომელიც აჩვენებს მენიუს, deskbar, მკაცრად მიბმული გზაზე.

ბატონი. waddlesplash განმარტავს ამას:

"Deskbar" ამ შემთხვევაში უნდა იქნას გაგებული, როგორც ერთგვარი ზოგადი ტერმინი (ისევე როგორც "დავალებების პანელი", რომელიც ეხება როგორც Windows აპლიკაციას, ასევე ზოგად კონცეფციას). კარგი, მას შემდეგ deskbar, და არა "Deskbar", ამის გაგება ასევე შეიძლება ანალოგიურად.

2 "თითქმის იდენტური" დირექტორია აპლიკაციებით

რატომ არის 2 დირექტორია აპლიკაციებით და ასევე რატომ არის ჩემი QtQuickApplication ერთში, მაგრამ არა მეორეში? (ბოლოს და ბოლოს, ეს არ არის ერთი სისტემური, არამედ მეორე მომხმარებელი, რაც პირადად ჩემთვის გასაგები იქნება).
მე ნამდვილად დაბნეული ვარ და ვფიქრობ, რომ ეს უნდა იყოს ერთიანი.

კომენტარი ბატონის მიერ. ჭექა-ქუხილი

აპლიკაციების კატალოგი შეიცავს აპლიკაციებს, რომლებიც არ არის საჭირო მენიუში. მაგრამ მენიუს მდგომარეობა ნამდვილად საჭიროებს გაუმჯობესებას, რათა ის უფრო კონფიგურირებადი გახდეს.

განაცხადი, ან არ მოხდება 😉

მაინტერესებდა: მართლა საჭიროა აპლიკაციების მასპინძლობა /system/apps, თუ მომხმარებლები ხედავენ მათ იქ, არასასურველია. იქნებ ჯობია სხვა ადგილას განთავსდეს, სადაც მომხმარებელი არ შეხვდება? ისევე, როგორც ეს კეთდება Mac OS X-ში, სადაც არის პაკეტების შინაარსი .app, რომელიც არ უნდა იყოს ხილული მომხმარებლისთვის /Applications, იმალება /სისტემის/ბიბლიოთეკის/…“-ის სიღრმეში.

რაც შეეხება დამოკიდებულებებს?

ვფიქრობ, ღირს დამოკიდებულებების დაკონკრეტება როგორმე, არა? შეიძლება თუ არა Qt ჩაითვალოს Haiku-ს ინსტალაციის სავალდებულო ნაწილად ნაგულისხმევად? არა! Qt არ არის დაინსტალირებული ნაგულისხმევად. შეუძლია თუ არა პაკეტის შემქმნელს ავტომატურად აღმოაჩინოს დამოკიდებულებები ELF ფაილების შემოწმებით? მითხრეს, რომ HaikuPorter ამას რეალურად აკეთებს, მაგრამ package არა. ეს იმიტომ ხდება, რომ ის უბრალოდ "პაკეტების შემქმნელია", რომელიც მხოლოდ თავად ქმნის ფაილებს hpkg.

უნდა გახდეს თუ არა ჰაიკუ უფრო დახვეწილი პოლიტიკის დამატებით, რომ პაკეტს არ უნდა ჰქონდეს დამოკიდებულება ჰაიკუს გარეთ პაკეტებზე? haikuports? (მე მსურს, რადგან ასეთი პოლიტიკა ბევრად გაადვილებს საქმეს - სისტემას შეეძლება ავტომატურად გადაჭრას ნებისმიერი ადგილიდან ჩამოტვირთული პაკეტის დამოკიდებულებები, დამატებითი პაკეტის წყაროების არევის გარეშე.)

ბატონი. waddlesplash განმარტავს:

ჩვენ არ გვსურს დეველოპერების თავისუფლების იმდენად შეზღუდვა, რადგან აშკარაა, რომ თუ CompanyX-ს სურს მხარი დაუჭიროს საკუთარი პროგრამული უზრუნველყოფის კომპლექტს დამოკიდებულებით (და, შესაბამისად, საცავებით), ის ამას სრულიად თავისუფლად გააკეთებს.

ამ შემთხვევაში, შეიძლება ღირდეს რეკომენდაცია, რომ მესამე მხარის პაკეტებმა თავიდან აიცილონ დამოკიდებულება ყველაფერზე, რომელიც არ შედის haikuports-ში, სრულად შეფუთვით ყველაფერი, რაც საჭიროა აპლიკაციასთან ერთად. მაგრამ მე ვფიქრობ, რომ ეს არის ამ სერიის მომავალი სტატიის თემა. [მიდის ავტორი AppImage-ისკენ? - დაახლ. მთარგმნელი]

აპლიკაციის ხატის დამატება

რა მოხდება, თუ მსურს დავამატო ერთ-ერთი სუფთა ჩაშენებული ხატულა ჩემი ახლად შექმნილი აპლიკაციის რესურსებს? გამოდის, რომ ეს საოცარი თემაა, ამიტომ შემდეგი სტატიის საფუძველი იქნება.

როგორ მოვაწყოთ უწყვეტი აპლიკაციების შექმნა?

წარმოიდგინეთ პროექტი, როგორიცაა Inkscape (დიახ, ვიცი, რომ ის ჯერ არ არის ხელმისაწვდომი ჰაიკუში, მაგრამ მოსახერხებელია მასზე ჩვენება). მათ აქვთ წყაროს კოდის საცავი https://gitlab.com/inkscape/inkscape.
ყოველ ჯერზე, როცა ვინმე ასრულებს ცვლილებებს საცავში, დაიწყება build pipelines, რის შემდეგაც ცვლილებები ავტომატურად ტესტირება, შენდება და აპლიკაცია შეფუთულია სხვადასხვა პაკეტებში, მათ შორის AppImage for Linux (დამოუკიდებელი აპლიკაციის პაკეტი, რომელიც შეიძლება ჩამოტვირთოთ ადგილობრივი ტესტირებისთვის, მიუხედავად იმისა. რა შეიძლება იყოს ან არ იყოს დაინსტალირებული სისტემაში [Ვიცოდი! - დაახლ. მთარგმნელი]). იგივე ხდება ფილიალების შერწყმის ყველა მოთხოვნასთან დაკავშირებით, ასე რომ თქვენ შეგიძლიათ ჩამოტვირთოთ აპლიკაცია შერწყმის მოთხოვნაში შემოთავაზებული კოდიდან შერწყმამდე.

მოთხოვნების შერწყმა build სტატუსებთან და შედგენილი ორობითი ფაილების ჩამოტვირთვის შესაძლებლობა, თუ build წარმატებულია (მონიშნულია მწვანეში)

კონსტრუქცია მუშაობს Docker კონტეინერებში. GitLab გთავაზობთ უფასო რნერებს Linux-ზე და ვფიქრობ, რომ შესაძლებელია თქვენი საკუთარი მორბენლების ჩართვა (სხვათა შორის, მე ვერ ვხედავ, როგორ იმუშავებს ეს Haiku-ს მსგავსი სისტემებისთვის, რომელსაც ვიცი, რომ არ აქვს Docker ან ექვივალენტი, მაგრამ ასევე FreeBSD-სთვის არ არსებობს Docker, ამიტომ ეს პრობლემა არ არის უნიკალური ჰაიკუსთვის).

იდეალურ შემთხვევაში, Haiku აპლიკაციები შეიძლება აშენდეს Docker კონტეინერში Linux-ისთვის. ამ ვითარებაში, ჰაიკუს შეკრება შეიძლება შევიდეს არსებულ მილსადენებში. არის ჯვარედინი შემდგენელები? ან უნდა მივბაძო ყველა ჰაიკუს Docker კონტეინერში QEMU/KVM-ის მსგავსი რაღაცის გამოყენებით (თუ ვივარაუდოთ, რომ ის ასე იმუშავებს Docker-ში)? სხვათა შორის, ბევრი პროექტი იყენებს მსგავს პრინციპებს. მაგალითად, Scribus აკეთებს ამას - ის უკვე ხელმისაწვდომია ჰაიკუსთვის. დადგება დღე, როცა შემიძლია გავაგზავნო ასეთი გაიყვანეთ მოთხოვნები სხვა პროექტებზე ჰაიკუს მხარდაჭერის დასამატებლად.

ერთ-ერთი დეველოპერი განმარტავს:

სხვა პროექტებისთვის, რომლებსაც სურთ თავად შექმნან პაკეტები, მხარდაჭერილია რეგულარული CMake/CPack მეთოდი. სხვა build სისტემების მხარდაჭერა შესაძლებელია პაკეტის build პროგრამის პირდაპირ დარეკვით, რაც კარგია, თუ ხალხი დაინტერესებულია ამით. გამოცდილება გვიჩვენებს: აქამდე დიდი ინტერესი არ ყოფილა, ამიტომ haikuporter ჩვენთვის მოსახერხებელი მუშაობდა, მაგრამ, საბოლოო ჯამში, ორივე მეთოდი ერთად უნდა მუშაობდეს. ჩვენ უნდა შემოვიტანოთ ინსტრუმენტების ნაკრები Linux-დან ან სხვა სერვერის ოპერაციული სისტემიდან პროგრამული უზრუნველყოფის ჯვარედინი მშენებლობისთვის (Haiku არ არის შექმნილი სერვერებზე გასაშვებად).

ოვაციას ვაძლევ. Linux-ის რეგულარული მომხმარებლები ატარებენ მთელ ამ დამატებით დატვირთვას და დამატებით ბარგს (უსაფრთხოება, მკაცრი კონტროლი და ა.შ.), რაც აუცილებელია სერვერის ოპერაციული სისტემისთვის, მაგრამ არა პირადისთვის. ასე რომ, მე სრულიად ვეთანხმები, რომ Haiku აპლიკაციების შექმნა Linux-ზე არის გასავლელი გზა.

დასკვნა

POSIX აპლიკაციების პორტირება ჰაიკუზე შესაძლებელია, მაგრამ შეიძლება უფრო ძვირი იყოს, ვიდრე ტიპიური რეკონსტრუქცია. მე ნამდვილად დიდხანს დავრჩებოდი ამით, რომ არა #haiku არხის ადამიანების დახმარება irc.freenode.net ქსელში. მაგრამ ისინიც კი ყოველთვის ვერ ხედავდნენ, რა იყო არასწორი.

Qt-ში დაწერილი აპლიკაციები მარტივი გამონაკლისია. მე შევკრიბე მარტივი დემო აპლიკაცია უპრობლემოდ.

მარტივი აპლიკაციებისთვის პაკეტის აგება ასევე საკმაოდ მარტივია, მაგრამ მხოლოდ „ტრადიციულად გამოშვებული“, ე.ი. ჰაიკუპორტებში მხარდაჭერისთვის განკუთვნილი ვერსიირებული წყაროს კოდის არქივების მქონე. GitHub-ის უწყვეტი კონსტრუქციისთვის (ცვლილებების ყოველი შესრულებისთვის) ყველაფერი არც ისე მარტივია. აქ ჰაიკუ უფრო ჰგავს Linux დისტრიბუციას, ვიდრე შედეგს Mac-ზე, სადაც XCode-ში ღილაკზე „Build“ დაწკაპუნებისას მიიღებთ პაკეტს. .app, მზად არის დისკის სურათში ჩასართავად .dmg, ჩამოსატვირთად მომზადდა ჩემს ვებგვერდზე.
"სერვერის" ოპერაციულ სისტემაზე დაფუძნებული აპლიკაციების უწყვეტი აშენება, მაგალითად, Linux, სავარაუდოდ შესაძლებელი გახდება, თუ იქნება მოთხოვნა დეველოპერებისგან, მაგრამ ამ დროისთვის Haiku პროექტს აქვს სხვა, უფრო აქტუალური ამოცანები.

თავად სცადე! ყოველივე ამის შემდეგ, Haiku პროექტი უზრუნველყოფს სურათებს DVD ან USB-დან ჩატვირთვისთვის, გენერირებული ყოველდღიური. ინსტალაციისთვის, უბრალოდ გადმოწერეთ სურათი და ჩაწერეთ იგი USB ფლეშ დრაივზე გამოყენებით ეტჩერი

გაქვთ შეკითხვები? გეპატიჟებით რუსულენოვანზე დეპეშა არხი.

შეცდომის მიმოხილვა: როგორ გავისროლოთ ფეხში C და C++-ში. Haiku OS რეცეპტების კოლექცია

მდებარეობა ავტორი თარგმანი: ეს არის მეხუთე სტატია სერიის ჰაიკუს შესახებ.

სტატიების სია: პირველი მეორე მესამე მეოთხე

წყარო: www.habr.com