היום החמישי שלי עם הייקו: בוא נעביר כמה תוכניות

TL; DR: משתמש חדש ראה את Haiku בפעם הראשונה, מנסה להעביר כמה תוכניות מעולם לינוקס.

התוכנית הראשונה שלי ב-Haiku המועברת, ארוזה בפורמט hpkg שלה

לאחרונה גיליתי את Haiku, מערכת הפעלה מפתיעה לטובה למחשבים אישיים.
היום אלמד כיצד להעביר תוכניות חדשות למערכת הפעלה זו. המוקד העיקרי הוא תיאור החוויה הראשונה של המעבר להייקו מנקודת מבטו של מפתח לינוקס. אני מתנצל על כל טעויות מטופשות שעשיתי בדרך, מכיוון שלא עבר אפילו שבוע מאז שהורדתי את הייקו לראשונה.

אני רוצה להשיג שלוש מטרות:

• העבר יישום CLI פשוט
• העבר יישום מ-GUI ל-Qt
• לאחר מכן ארוז אותם בפורמט hpkg (מכיוון שאני עדיין חושב על התאמת AppDir ו-AppImage עבור Haiku...)

בואו נתחיל. בקטעים תיעוד и התפתחות, כמו גם ב ויקי מ- HaikuPorts מצאתי את הכיוון הנכון. יש אפילו ספר PDF מקוון BeOS: העברה של יישום יוניקס.
467 עמודים - וזה מ-1997! זה מפחיד להסתכל פנימה, אבל אני מקווה לטוב. דברי המפתח מעודדים: "זה לקח הרבה זמן כי BeOS לא היה תואם POSIX", אבל Haiku "לרוב" כבר ככה.

העברה של יישום CLI פשוט

המחשבה הראשונה הייתה לנייד את האפליקציה avrdude, אבל, כפי שהתברר, זה כבר עשו לפני זמן רב.

ניסיון ראשון: אין מה לצפות

מה שאני לא יכול להבין זה כבר אפליקציות הועברו להייקו במשך יותר מ-10 שנים - למרות העובדה שמערכת ההפעלה עצמה עדיין לא גרסה 1.0.

ניסיון שני: צריך לכתוב מחדש

אז אני אשתמש ptouch-770, CLI לשליטה במדפסת Brother P-Touch 770 שבה אני משתמש להדפסת תוויות.
אני מדפיס עליו תוויות שונות, ואולי כבר ראיתם את זה במאמר הקודם. קצת קודם לכן, כתבתי תוכנית מעטפת GUI קטנה ב-Python (מכיוון שהיא ב-Gtk+, היא תצטרך להיכתב מחדש, וזו סיבה טובה ללמוד).

מדפסת תוויות Brother P-Touch 770. האם זה יעבוד עם Haiku?

מנהל החבילות של 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 מבוסס מדי על לינוקס ולכן אינו קיים עבור Haiku. מה שאומר שאני צריך לערוך את קוד המקור שאני מנסה להדר.
אה, אתה לא יכול לקפוץ מעל הראש, ואני אפילו לא יודע מאיפה להתחיל.

ניסיון שלישי

זה יהיה נחמד לקבל tmate עבור Haiku, אז הייתי מאפשר למפתחי Haiku להתחבר לסשן הטרמינל שלי - למקרה שמשהו ישתבש. ההוראות די פשוטות:

./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 - מכונות וירטואליות).

בניית ה-sgpack המתוקן ב-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 לכן you

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

אדון. waddlesplash אומר לך איפה לחפור:

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

הם הסבירו לי שיש עוד משהו ב-libnetwork בנוסף ל-libresolv ב-Haiku. כנראה שצריך לערוך עוד את הקוד. צריך לחשוב…

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.

העברת יישום ה-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-creator (זה קורס לי, דיווח שגיאות)

לא ברור מה לעשות. אני מניח שאני צריך מדריך למתחילים בסגנון Hello World, באופן אידיאלי סרטון. זה יהיה נחמד לקבל גם היכרות נוחה עם HaikuPorter, כפי שנעשה ב-GNU hello.

קראתי את הדברים הבאים:

haikuporter הוא כלי ליצירת פרויקטי חבילה נפוצים עבור Haiku. הוא משתמש במאגר HaikuPorts כבסיס לכל החבילות. מתכוני הייקופורטר משמשים ליצירת חבילות.

בנוסף, אני מגלה ש:

אין צורך לאחסן מתכונים באחסון 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!

עלתה שאלה מעניינת. אם אוסיף צ'קsum למתכון - האם הוא יתאים ל-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.

אולי 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 לא מאובטח!) ועדיין מנסה לפרוק משהו.

על פי אדון. waddlesplash:

ובכן, כן, הסיבה הייתה הרצון לבדוק את תקינות הנתונים שהתקבלו להרכבה. אחת האפשרויות היא לאמת את סכום הבדיקה של הארכיון, אך ניתן, כמובן, לגיבוב קבצים בודדים, אשר לא יושמו, מכיוון זה לוקח הרבה יותר זמן. התוצאה של זה היא "חוסר הביטחון" של 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 ומאגר הייקופורטים אין לזה תחושה של "פשוט עובד", אבל בתור מפתח, יש כמה דברים שאני אוהב בעבודה עם Haiku. לרוב, זה דומה ל-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 מסביר את זה:

יש להבין את "שורת השולחן" במקרה זה כסוג של מונח כללי (בדומה ל"שורת המשימות", המתייחס הן לאפליקציית Windows והן למושג הכללי). ובכן, מאז זה deskbar, לא "סרגל השולחן", ניתן גם להבין זאת בצורה דומה.

2 ספריות "כמעט זהות" עם אפליקציות בהן

למה יש 2 ספריות עם יישומים, וגם למה ה-QtQuickApplication שלי נמצא באחת, אבל לא באחרת? (הרי זה לא מערכת אחת, אלא משתמש שני, מה שיהיה מובן לי אישית).
אני ממש מבולבל ואני חושב שזה צריך להיות מאוחד.

הערה של מר. waddlesplash

קטלוג האפליקציות מכיל יישומים שאינם נחוצים בתפריט. אבל המצב עם התפריט באמת צריך להשתפר, כדי להפוך אותו להתאמה אישית יותר.

יישום, או שזה לא יקרה 😉

תהיתי: האם באמת יש צורך לארח אפליקציות /system/apps, אם משתמשים רואים אותם שם, זה לא רצוי. אולי עדיף למקם אותם במקום אחר שבו המשתמש לא יתקל בהם? בדיוק כמו שזה נעשה ב-Mac OS X, שבו התוכן של חבילות .app, אשר לא אמור להיות גלוי למשתמש ב /Applications, מתחבא במעמקי /System/Library/…“`.

מה לגבי תלות?

אני חושב שכדאי לציין את התלות איכשהו, נכון? האם Qt יכול להיחשב כחלק חובה מהתקנת Haiku כברירת מחדל? לא! Qt אינו מותקן כברירת מחדל. האם בונה חבילות יכול לזהות תלות אוטומטית על ידי בדיקת קבצי ELF? אמרו לי שהאיקופורטר באמת עושה את זה, אבל package לא. זה בגלל שזה רק "בונה חבילות" שפשוט יוצר קבצים בעצמו hpkg.

האם יש לשפר את הייקו על ידי הוספת מדיניות לפיה לחבילה אין תלות בחבילות מחוץ להייקו? haikuports? (הייתי רוצה, כי מדיניות כזו תקל הרבה יותר על הדברים - המערכת תוכל לפתור באופן אוטומטי את התלות של כל חבילה שהורדו מכל מקום, מבלי להתעסק עם מקורות חבילה נוספים.)

אדון. waddlesplash מסביר:

לא היינו רוצים להגביל כל כך את החופש של מפתחים, כי ברור שאם CompanyX רוצה לתמוך בסט תוכנות משלה עם תלות (ולכן מאגר), היא תעשה זאת באופן חופשי לחלוטין.

במקרה כזה, אולי כדאי להמליץ ​​לחבילות של צד שלישי להימנע מתלות בכל דבר שאינו כלול ב-haikuports על ידי אריזה מלאה של כל הדרוש עם האפליקציה. אבל אני חושב שזה נושא למאמר עתידי בסדרה זו. [האם המחבר הולך לכיוון AppImage? - משוער. מְתוּרגְמָן]

הוספת סמל אפליקציה

מה אם אני רוצה להוסיף את אחד מהסמלים המובנים המסודרים למשאבים של היישום החדש שלי שנוצר? מסתבר שזהו נושא מדהים ולכן הוא יהווה את הבסיס למאמר הבא.

כיצד לארגן בניית אפליקציות מתמשכת?

דמיינו פרויקט כמו Inkscape (כן, אני מודע לכך שהוא עדיין לא זמין בהייקו, אבל נוח להצגה בו). יש להם מאגר קוד מקור https://gitlab.com/inkscape/inkscape.
בכל פעם שמישהו מבצע את השינויים שלו במאגר, מופעלים צינורות בנייה, שלאחריהם השינויים נבדקים, נבנים אוטומטית והאפליקציה נארזת בחבילות שונות, כולל AppImage עבור Linux (חבילת אפליקציות עצמאית שניתן להוריד לבדיקה מקומית ללא קשר מה עשוי להיות מותקן במערכת או לא [ידעתי! - משוער. מְתוּרגְמָן]). אותו דבר קורה בכל בקשת מיזוג סניפים, כך שתוכל להוריד את האפליקציה הבנויה מהקוד המוצע בבקשת המיזוג לפני המיזוג.

מיזוג בקשות עם סטטוסים של בנייה ויכולת להוריד את הקבצים הבינאריים הקומפיליים אם הבנייה הצליחה (מסומן בירוק)

ה-build פועל בקונטיינרים של Docker. GitLab מציעה רצים בחינם בלינוקס, ואני חושב שאולי אפשר לכלול רצים משלך (אגב, אני לא רואה איך זה יעבוד עבור מערכות כמו Haiku, שאני יודע שאין להן Docker או מקבילה, אבל גם עבור FreeBSD אין Docker, אז בעיה זו אינה ייחודית להייקו).

באופן אידיאלי, ניתן לבנות יישומי Haiku בתוך קונטיינר Docker עבור לינוקס. במצב זה, ניתן להכניס את המכלול עבור הייקו לצינורות קיימים. האם יש מהדרים צולבים? או שעלי לחקות את כל הייקו בתוך קונטיינר Docker באמצעות משהו כמו QEMU/KVM (בהנחה שזה יעבוד כך בתוך Docker)? אגב, פרויקטים רבים משתמשים בעקרונות דומים. לדוגמה, Scribus עושה זאת - זה כבר זמין עבור Haiku. יום אחד יבוא היום שבו אוכל לשלוח כזה משוך בקשות לפרויקטים אחרים כדי להוסיף תמיכת Haiku.

אחד המפתחים מסביר:

עבור פרויקטים אחרים המעוניינים ליצור חבילות בעצמם, שיטת CMake/CPack הרגילה נתמכת. ניתן לתמוך במערכות בנייה אחרות על ידי קריאה ישירה לתוכנית הבנייה של החבילה, וזה בסדר אם אנשים מתעניינים בה. הניסיון מלמד: עד כה לא הייתה עניין רב, אז הייקופורטר עבד כמו שצריך עבורנו, אבל, בסופו של דבר, שתי השיטות צריכות לעבוד יחד. עלינו להציג סט כלים לתוכנות צולבות מ-Linux או כל מערכת הפעלה אחרת של שרתים (Haiku לא נועד לרוץ על שרתים).

אני נותן כפיים סוערת. משתמשי לינוקס רגילים נושאים את כל העומס הנוסף הזה והמטען הנוסף הזה (אבטחה, בקרה קפדנית וכו') הדרוש למערכת הפעלה של שרת, אבל לא למערכת הפעלה אישית. אז אני מסכים לחלוטין שהיכולת לבנות אפליקציות הייקו בלינוקס היא הדרך ללכת.

מסקנה

העברה של יישומי POSIX להייקו אפשרית, אך עשויה להיות יקרה יותר מאשר בנייה מחדש טיפוסית. בהחלט הייתי תקוע עם זה להרבה זמן אלמלא העזרה של אנשים מערוץ #haiku ברשת irc.freenode.net. אבל אפילו הם לא תמיד ראו מיד מה לא בסדר.

יישומים שנכתבו ב-Qt הם חריג קל. הרכבתי יישום הדגמה פשוט ללא בעיות.

בניית חבילה ליישומים פשוטים היא גם די קלה, אבל רק עבור אלה "ששוחררו באופן מסורתי", כלומר. בעל ארכיוני קוד מקור מנוסחים המיועדים לתמיכה ב-haikuports. עבור בנייה מתמשכת (בנייה עבור כל מחויבות של שינויים) עם GitHub, נראה שהכל לא כל כך פשוט. כאן הייקו מרגיש יותר כמו הפצת לינוקס מאשר התוצאה ב-Mac, כאשר כשאתה לוחץ על כפתור "Build" ב-XCode אתה מקבל חבילה .app, מוכן להכנס לתמונת דיסק .dmg, מוכן להורדה באתר שלי.
בנייה רציפה של אפליקציות המבוססות על מערכת הפעלה "שרת", למשל, לינוקס, תתאפשר ככל הנראה אם ​​יהיה ביקוש מהמפתחים, אבל כרגע לפרויקט Haiku יש משימות אחרות, דחופות יותר.

נסה זאת בעצמך! אחרי הכל, פרויקט Haiku מספק תמונות לאתחול מ-DVD או USB, שנוצרו יומי. כדי להתקין, פשוט הורד את התמונה וכתוב אותה לכונן הבזק באמצעות חָרָט

יש לך שאלות? אנו מזמינים אותך לדוברי רוסית ערוץ מברק.

סקירת שגיאות: איך לירות לעצמך ברגל ב-C ו-C++. אוסף מתכונים של Haiku OS

מן המחבר תרגום: זהו המאמר החמישי בסדרה על הייקו.

רשימת מאמרים: Первая ב Третья רביעית

מקור: www.habr.com