پنجمین روز من با هایکو: اجازه دهید چند برنامه را پورت کنیم

پنجمین روز من با هایکو: اجازه دهید چند برنامه را پورت کنیم

TL؛ DR: یک تازه کار برای اولین بار هایکو را دید که سعی می کرد برخی از برنامه ها را از دنیای لینوکس پورت کند.

پنجمین روز من با هایکو: اجازه دهید چند برنامه را پورت کنیم
اولین برنامه هایکو پورت شده من که در قالب hpkg بسته بندی شده است

تازه من Haiku را کشف کردم، یک سیستم عامل شگفت آور خوب برای رایانه های شخصی.
امروز یاد خواهم گرفت که چگونه برنامه های جدید را به این سیستم عامل منتقل کنم. تمرکز اصلی شرح اولین تجربه تغییر به هایکو از دیدگاه یک توسعه دهنده لینوکس است. من بابت اشتباهات احمقانه ای که در این مسیر مرتکب شدم عذرخواهی می کنم، زیرا از اولین بارگیری هایکو حتی یک هفته نگذشته است.

من می خواهم به سه هدف برسم:

  • پورت یک برنامه ساده CLI
  • پورت یک برنامه از رابط کاربری گرافیکی به Qt
  • سپس آنها را در قالب hpkg بسته بندی کنید (از آنجایی که من هنوز در فکر تطبیق AppDir و AppImage برای هایکو هستم...)

بیا شروع کنیم. در بخش ها مستندات и توسعهو همچنین در ویکی از HaikuPorts مسیر درست را پیدا کردم. حتی یک کتاب PDF آنلاین نیز وجود دارد BeOS: انتقال یک برنامه یونیکس.
467 صفحه - و این مربوط به سال 1997 است! نگاه کردن به درون ترسناک است، اما من به بهترین ها امیدوارم. سخنان توسعه دهنده دلگرم کننده است: "زمان زیادی طول کشید زیرا BeOS سازگار با POSIX نبود" اما Haiku "در بیشتر موارد" قبلاً همینطور است.

انتقال یک برنامه ساده CLI

اولین فکر پورت کردن اپلیکیشن بود avrdude، اما، همانطور که معلوم شد، این در حال حاضر است ساخته شده مدت ها پیش.

اول امتحان کنید: چیزی برای تماشا نیست

چیزی که من نمی توانم درک کنم این است که قبلا برنامه ها بیش از 10 سال است که به هایکو منتقل شده اند - با وجود این واقعیت که خود سیستم عامل هنوز حتی نسخه 1.0 نیست.

تلاش دوم: نیاز به بازنویسی

پس من استفاده خواهم کرد ptouch-770، CLI برای کنترل چاپگر Brother P-Touch 770 که من برای چاپ برچسب ها استفاده می کنم.
من برچسب های مختلفی را روی آن چاپ می کنم و ممکن است قبلاً آن را در مقاله قبلی دیده باشید. کمی قبل از آن، یک برنامه بسته بندی رابط کاربری گرافیکی کوچک در پایتون نوشتم (از آنجایی که در Gtk+ است، باید بازنویسی شود و این دلیل خوبی برای یادگیری است).

پنجمین روز من با هایکو: اجازه دهید چند برنامه را پورت کنیم
چاپگر لیبل برادر P-Touch 770 آیا با هایکو کار می کند؟

مدیر بسته هایکو درباره کتابخانه ها و دستورات می داند، بنابراین اگر هنگام اجرا پیام «نمی توانم 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 بیش از حد مبتنی بر لینوکس باشد و بنابراین برای هایکو وجود ندارد. این بدان معناست که من باید کد منبعی را که می‌خواهم کامپایل کنم، ویرایش کنم.
اوه، شما نمی توانید از بالای سر خود بپرید، و من حتی نمی دانم از کجا شروع کنم.

تلاش سوم

داشتنش خوبه 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

در این مرحله متوجه شدم که انتقال یک برنامه به هایکو به دانشی بسیار بیشتر از نیاز برای یک بازسازی ساده نیاز دارد.
من با توسعه دهندگان هایکو دوستانه صحبت کردم، معلوم شد که یک اشکال در msgpack وجود دارد و بعد از چند دقیقه یک پچ در HaikuPorts می بینم. من می توانم با چشمان خود ببینم که چگونه بسته اصلاح شده است رفتن به اینجا (buildslave - ماشین های مجازی).

پنجمین روز من با هایکو: اجازه دهید چند برنامه را پورت کنیم
ساخت msgpack اصلاح شده در buildmaster

در بین زمان ها من یک پچ به upstream ارسال می کنم برای افزودن پشتیبانی هایکو به 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 در هایکو چیز دیگری در libnetwork وجود دارد. ظاهرا کد نیاز به ویرایش بیشتر دارد. نیاز به فکر کردن…

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

همین مورد، فقط در پروفایل. گوگل کرد و این را پیدا کرد. اگر اضافه کنید -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

"شناسه پورت بد" در حال حاضر مانند یک کارت ویزیت است هایکو. شاید کسی ایده ای داشته باشد که مشکل چیست و چگونه می توان آن را برطرف کرد؟ اگر چنین است، مقاله را به روز می کنم. پیوند به GitHub.

انتقال برنامه رابط کاربری گرافیکی به 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.

از چه چیزی شروع کنم؟ هیچ سند ساده ای وجود ندارد، من به کانال #هایکو در irc.freenode.net می روم و می شنوم:

  • تیم package - یک راه سطح پایین برای ایجاد بسته ها. در بیشتر موارد، PackageInfo برای او کافی است، همانطور که در بخش "تبدیل آن به یک بسته hpkg مناسب" توضیح داده شد.
  • من نیاز دارم کاری انجام بدم چنین
  • می توانید استفاده کنید hpkg-creator (برای من خراب می شود، گزارش خطا)

معلوم نیست چه کار باید کرد. حدس می‌زنم به راهنمای مبتدی سبک Hello World نیاز دارم، در حالت ایده‌آل به یک ویدیو. خوب است که یک معرفی راحت برای HaikuPorter نیز داشته باشیم، همانطور که در سلام GNU انجام می شود.

من در حال خواندن مطالب زیر هستم:

haikuporter ابزاری برای ایجاد پروژه های بسته مشترک برای هایکو است. از مخزن HaikuPorts به عنوان پایه ای برای همه بسته ها استفاده می کند. دستور العمل های Haikuporter برای ایجاد بسته ها استفاده می شود.

علاوه بر این، متوجه می شوم که:

نیازی به ذخیره دستور العمل ها در فضای ذخیره سازی HaikuPorts نیست. می توانید یک مخزن دیگر بسازید، دستور العمل ها را در آن قرار دهید و سپس به haikuporter اشاره کنید.

همان چیزی است که من نیاز دارم - اگر به دنبال راهی برای انتشار عمومی بسته نباشم. اما این موضوع برای پست دیگری است.

نصب هایکوپورتر و هایکوپورت

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 قرار دارد، به دنبال unpacker نباشد.

شاید 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

از روی عادت قدیمی می روم از افراد خوب در کانال #هایکو در شبکه 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 است، مجموعه‌ای از ابزارها برای ساخت بیلدهای لینوکس: بسیار قدرتمند، با رویکردی سیستماتیک، اما برای برنامه کوچک «سلام جهان» من بیش از حد است.

باز هم طبق گفته آقای waddlesplash:

در واقع، HaikuPorter به طور پیش‌فرض کاملاً سخت‌گیرانه است (به‌علاوه یک حالت پرز و همچنین یک حالت سخت‌گیرانه وجود دارد که آن را حتی سخت‌تر می‌کند!)، اما فقط به این دلیل که به جای ایجاد بسته‌ها، بسته‌هایی ایجاد می‌کند که کار می‌کنند. به همین دلیل از وابستگی های اعلام نشده، وارد نشدن صحیح کتابخانه ها، نسخه های نادرست و غیره شکایت دارد. هدف این است که قبل از اینکه کاربر از آن مطلع شود، همه مشکلات، از جمله مشکلات آینده، حل شود (به همین دلیل است که نصب avrdude ممکن نبود، زیرا وابستگی در واقع در دستور پخت مشخص شده بود). کتابخانه ها فقط بسته های فردی یا حتی نسخه های خاص SO نیستند. HaikuPorter تضمین می کند که همه اینها در خود دستور العمل ها رعایت می شود تا از خطا در هنگام اجرا جلوگیری شود.

در اصل، این سطح از سختگیری هنگام ایجاد یک سیستم عامل توجیه می شود، اما به نظر من برای برنامه "سلام جهان" غیر ضروری است. تصمیم گرفتم چیز دیگری را امتحان کنم.

ساخت برنامه های کاربردی با فرمت hpkg با استفاده از دستور "package create".

شاید، این آیا دستورالعمل های ساده برای من بهتر کار می کنند؟

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 در لینوکس چرا اطلاعات "پنهان" را به منبع و ویژگی سیستم فایل تبدیل نمی کنیم؟

چیزی که به خصوص ظریف نیست نام (برخی) برنامه ای است که منو را نشان می دهد، deskbar، در طول راه به سختی گره خورده است.

آقای. waddlesplash این را توضیح می دهد:

"Deskbar" در این مورد باید به عنوان یک نوع اصطلاح کلی در نظر گرفته شود (تقریباً به همان روش "Taskbar" که هم به برنامه ویندوز و هم به مفهوم کلی اشاره دارد). خوب، از این زمان deskbar، نه "Deskbar"، این را نیز می توان به روشی مشابه درک کرد.

پنجمین روز من با هایکو: اجازه دهید چند برنامه را پورت کنیم
2 دایرکتوری "تقریبا یکسان" با برنامه های کاربردی در آنها

چرا 2 دایرکتوری با برنامه وجود دارد، و همچنین چرا QtQuickApplication من در یکی است، اما در دیگری نیست؟ (بالاخره، این یک سیستم نیست، بلکه یک کاربر دوم است که شخصاً برای من قابل درک است).
من واقعا گیج شده ام و فکر می کنم این باید یکپارچه شود.

نظر توسط آقای آب پاش

کاتالوگ برنامه ها شامل برنامه هایی است که در منو مورد نیاز نیستند. اما وضعیت منو واقعاً نیاز به بهبود دارد تا قابل تنظیم تر شود.

برنامه، وگرنه اتفاق نمی افتد 😉

من تعجب کردم: آیا واقعاً لازم است که برنامه ها را میزبانی کنیم؟ /system/apps، اگر کاربران آنها را در آنجا ببینند، نامطلوب است. شاید بهتر باشد آنها را در جای دیگری قرار دهیم که کاربر با آنها برخورد نکند؟ درست همانطور که در Mac OS X انجام می شود، جایی که محتویات بسته ها وجود دارد .app، که نباید برای کاربر در آن قابل مشاهده باشد /Applications, پنهان شدن در اعماق /System/Library/…”`.

در مورد وابستگی ها چطور؟

من فکر می کنم ارزش دارد که وابستگی ها را به نوعی مشخص کنیم، درست است؟ آیا می توان Qt را به طور پیش فرض بخشی اجباری از نصب هایکو در نظر گرفت؟ جواب منفی! Qt به طور پیش فرض نصب نشده است. آیا یک سازنده بسته می تواند به طور خودکار وابستگی ها را با بررسی فایل های ELF تشخیص دهد؟ به من گفته شد که HaikuPorter در واقع این کار را انجام می دهد، اما package خیر دلیلش این است که این فقط یک "بسته ساز" است که به تنهایی فایل ها را ایجاد می کند hpkg.

آیا باید هایکو را با افزودن این سیاست پیچیده تر کرد که یک بسته نباید به بسته های خارج از هایکو وابسته باشد؟ haikuports? (من مایلم، زیرا چنین سیاستی کارها را بسیار آسان تر می کند - سیستم می تواند به طور خودکار وابستگی های هر بسته دانلود شده از هر نقطه را حل کند، بدون اینکه با منابع بسته اضافی دست و پنجه نرم کند.)

آقای. waddlesplash توضیح می دهد:

ما نمی خواهیم آزادی توسعه دهندگان را تا این حد محدود کنیم، زیرا بدیهی است که اگر CompanyX بخواهد مجموعه نرم افزارهای خود را با وابستگی ها (و بنابراین یک مخزن) پشتیبانی کند، این کار را کاملا آزادانه انجام خواهد داد.

در این صورت، ممکن است توصیه شود که بسته‌های شخص ثالث از وابستگی به هر چیزی که در هایکوپورت گنجانده نشده است، با بسته‌بندی کامل همه چیز مورد نیاز با برنامه، اجتناب کنند. اما فکر می کنم این موضوعی برای مقاله آینده در این مجموعه باشد. [آیا نویسنده به سمت AppImage می رود؟ - تقریبا مترجم]

افزودن نماد برنامه

اگر بخواهم یکی از نمادهای داخلی منظم را به منابع برنامه جدید خود اضافه کنم چه باید کرد؟ به نظر می رسد که این یک موضوع شگفت انگیز است، بنابراین مبنایی برای مقاله بعدی خواهد بود.

چگونه بیلدهای برنامه پیوسته را سازماندهی کنیم؟

پروژه ای مانند Inkscape را تصور کنید (بله، من می دانم که هنوز در هایکو در دسترس نیست، اما نمایش آن بر روی آن راحت است). آنها یک مخزن کد منبع دارند https://gitlab.com/inkscape/inkscape.
هر بار که شخصی تغییرات خود را در مخزن انجام می‌دهد، خطوط لوله بیلد راه‌اندازی می‌شود، پس از آن تغییرات به‌طور خودکار آزمایش، ساخته می‌شوند و برنامه در بسته‌های مختلف، از جمله AppImage برای لینوکس بسته‌بندی می‌شود (یک بسته برنامه مستقل که می‌توان بدون توجه به آزمایش محلی دانلود کرد. چه چیزی ممکن است روی سیستم نصب شود یا نباشد [میدونستم! - تقریبا مترجم]). همین اتفاق با هر درخواست ادغام شعبه می‌افتد، بنابراین می‌توانید قبل از ادغام، برنامه‌ای را که از کد پیشنهادی در درخواست ادغام ساخته شده است دانلود کنید.

پنجمین روز من با هایکو: اجازه دهید چند برنامه را پورت کنیم
درخواست‌های ادغام با وضعیت‌های ساخت و امکان دانلود باینری‌های کامپایل شده در صورت موفقیت‌آمیز ساختن (با رنگ سبز مشخص شده است)

بیلد در کانتینرهای Docker اجرا می شود. GitLab راه‌اندازهای رایگان را در لینوکس ارائه می‌دهد، و من فکر می‌کنم ممکن است رانرهای خودتان را نیز درج کنید (به هر حال، من نمی‌دانم که چگونه این کار برای سیستم‌هایی مانند Haiku که می‌دانم Docker یا معادل آن ندارند، کار کند، اما همچنین برای FreeBSD هیچ Docker وجود ندارد، بنابراین این مشکل منحصر به هایکو نیست).

در حالت ایده آل، برنامه های هایکو را می توان در داخل یک ظرف Docker برای لینوکس ساخت. در این شرایط، مونتاژ برای هایکو می تواند به خطوط لوله موجود وارد شود. آیا کامپایلرهای متقابل وجود دارد؟ یا باید با استفاده از چیزی مانند QEMU/KVM از تمام هایکو در داخل یک ظرف داکر شبیه سازی کنم (با فرض اینکه در داخل داکر اینطور کار کند)؟ به هر حال، بسیاری از پروژه ها از اصول مشابهی استفاده می کنند. به عنوان مثال، Scribus این کار را انجام می دهد - در حال حاضر برای هایکو در دسترس است. یه روزی میرسه که بتونم بفرستم چنین برای افزودن پشتیبانی هایکو، درخواست ها را به پروژه های دیگر بکشید.

یکی از توسعه دهندگان توضیح می دهد:

برای پروژه های دیگری که مایل به ایجاد بسته ها هستند، روش معمولی CMake/CPack پشتیبانی می شود. سیستم های ساخت دیگر را می توان با تماس مستقیم با برنامه ساخت پکیج پشتیبانی کرد که اگر افراد به آن علاقه مند باشند خوب است. تجربه نشان می دهد: تا کنون علاقه زیادی وجود نداشته است، بنابراین haikuporter برای ما راحت کار کرد، اما، در نهایت، هر دو روش باید با هم کار کنند. ما باید مجموعه ای از ابزارها را برای نرم افزارهای متقابل از لینوکس یا هر سیستم عامل سرور دیگری معرفی کنیم (هایکو برای اجرا روی سرورها طراحی نشده است).

من به شدت تشویق می کنم. کاربران معمولی لینوکس این همه بار اضافی و چمدان اضافی (امنیتی، کنترل دقیق و غیره) را که برای یک سیستم عامل سرور ضروری است، اما برای یک سیستم شخصی، حمل می کنند. بنابراین من کاملا موافقم که امکان ساخت اپلیکیشن هایکو بر روی لینوکس راه حلی است.

نتیجه

انتقال برنامه های POSIX به هایکو ممکن است، اما ممکن است گران تر از بازسازی معمولی باشد. اگر کمک افرادی از کانال #هایکو در شبکه irc.freenode.net نبود قطعاً برای مدت طولانی درگیر این موضوع بودم. اما حتی آنها همیشه بلافاصله نمی دیدند چه چیزی اشتباه است.

برنامه هایی که با Qt نوشته شده اند یک استثنا هستند. من یک برنامه آزمایشی ساده را بدون هیچ مشکلی جمع کردم.

ساختن یک بسته برای برنامه های کاربردی ساده نیز بسیار آسان است، اما فقط برای برنامه های "به طور سنتی منتشر شده"، یعنی. داشتن آرشیوهای کد منبع نسخه شده برای پشتیبانی در هایکوپورت. برای ساخت پیوسته (ساخت برای هر تعهد تغییر) با GitHub، به نظر می رسد همه چیز چندان ساده نیست. در اینجا هایکو بیشتر شبیه یک توزیع لینوکس است تا نتیجه در مک، جایی که با کلیک بر روی دکمه "Build" در XCode یک بسته دریافت می کنید. .app، آماده درج در تصویر دیسک است .dmg، برای دانلود در وب سایت من آماده شده است.
ساخت مداوم برنامه های کاربردی مبتنی بر یک سیستم عامل "سرور"، به عنوان مثال، لینوکس، به احتمال زیاد در صورت وجود تقاضا از سوی توسعه دهندگان امکان پذیر خواهد شد، اما در حال حاضر پروژه هایکو وظایف مهم تری دارد.

خودت آن را امتحان کن! پس از همه، پروژه هایکو تصاویری را برای بوت شدن از DVD یا USB، تولید شده فراهم می کند روزانه. برای نصب، کافی است تصویر را دانلود کرده و با استفاده از درایو فلش USB آن را رایت کنید اتچر

سوالاتی دارید؟ شما را به روسی زبان دعوت می کنیم کانال تلگرام.

نمای کلی خطا: چگونه در C و C++ به پای خود شلیک کنید. مجموعه دستور العمل هایکو سیستم عامل

از نویسنده ترجمه: این پنجمین مقاله از مجموعه در مورد هایکو است.

فهرست مقالات: ابتدا دوم Третья چهارم

منبع: www.habr.com

اضافه کردن نظر