Haiku を始めて XNUMX 日目: いくつかのプログラムを移植してみましょう

TL; DR: Linux の世界からいくつかのプログラムを移植しようとしていた初心者が、Haiku を初めて目にしました。

私の最初の Haiku 移植プログラム (hpkg 形式でパッケージ化)

最近 私は、PC 用の驚くほど優れたオペレーティング システムである Haiku を発見しました。
今日は、このオペレーティング システムに新しいプログラムを移植する方法を学びます。 主な焦点は、Linux 開発者の観点から Haiku に切​​り替えた最初の体験の説明です。 Haiku を初めてダウンロードしてからまだ XNUMX 週間も経っていないため、途中で愚かな間違いを犯したことをお詫びします。

私は次の XNUMX つの目標を達成したいと考えています。

• 単純な CLI アプリケーションを移植する
• アプリケーションを GUI から Qt に移植する
• 次に、それらを hpkg 形式でパッケージ化します (AppDir と AppImage を Haiku に適応させることをまだ考えているため...)

始めましょう。 セクション内 ドキュメント и 開発、および ウィキ HaikuPorts より 正しい方向性を見つけました。 オンラインの PDF ブックもあります BeOS: Unix アプリケーションの移植.
467 ページ - これは 1997 年のものです。 中を見るのは怖いですが、うまくいくことを願っています。 「BeOS が POSIX に準拠していなかったため、時間がかかりました」という開発者の言葉は励みになりますが、Haiku は「ほとんどの場合」すでにそのようになっています。

単純な CLI アプリケーションの移植

最初に考えたのはアプリケーションを移植することでした アヴェルデ、しかし、結局のところ、これはすでに 完了しました 昔。

最初の試み: 見るものは何もありません

理解できないのは、すでにそれが アプリは 10 年以上にわたって Haiku に移植されてきました - OS 自体はまだバージョン 1.0 にもなっていないにもかかわらず。

XNUMX 回目の試行: 書き直す必要があります

だから私は使います ptouch-770, ラベルの印刷に使用している Brother P-Touch 770 プリンタを制御するための CLI。
色々なラベルを印刷しているのですが、前回の記事でご覧になった方もいるかもしれません。 少し前に、Python で小さな GUI ラッパー プログラムを書きました (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 は Linux ベースすぎるため、Haiku には存在しないのでしょう。 つまり、コンパイルしようとしているソースコードを編集する必要があります。
えー、頭から飛び越えることはできないし、どこから始めればいいのかさえわかりません。

XNUMX回目の試み

あればいいですね tmate Haiku の場合、何か問題が発生した場合に備えて、Haiku 開発者が私のターミナル セッションに接続できるようにします。 手順は非常に簡単です。

./autogen.sh
./configure
make
make install

良さそうなので、Haiku で試してみてはいかがでしょうか。

/Haiku/home> git clone https://github.com/tmate-io/tmate/Haiku/home> cd tmate//Haiku/home/tmate> ./autogen.sh
(...)/Haiku/home/tmate> ./configure
(...)
checking for libevent... no
checking for library containing event_init... no
configure: error: "libevent not found"/Haiku/home/tmate> pkgman install devel:libevent
(...)
The following changes will be made:
  in system:
    install package libevent21-2.1.8-2 from repository HaikuPorts
    install package libevent21_devel-2.1.8-2 from repository HaikuPorts
Continue? [yes/no] (yes) :
100% libevent21-2.1.8-2-x86_64.hpkg [965.22 KiB]
(...)
[system] Done.checking for ncurses... no
checking for library containing setupterm... no
configure: error: "curses not found"/Haiku/home/tmate> pkgman install devel:libcurses
(...)
*** Failed to find a match for "devel:libcurses": Name not found/Haiku/home/tmate> pkgman install devel:curses
(...)
*** Failed to find a match for "devel:curses": Name not found

このステップでは、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 に移植するには、単純な再構築に必要な知識よりもはるかに多くの知識が必要であることがわかりました。
親切な Haiku 開発者と話をしたところ、msgpack にバグがあることがわかり、数分後に HaikuPorts にパッチが表示されました。 パッケージが修正された様子を自分の目で確認できます ここに行きます (ビルドスレーブ - 仮想マシン)。

buildmaster で修正された msgpack をビルドする

その合間にアップストリームにパッチを送信します Haiku サポートを msgpack に追加するには.

XNUMX 分後、更新された msgpack はすでに Haiku で利用できるようになります。

/Haiku/home/tmate> pkgman update
(...)
The following changes will be made:
  in system:
    upgrade package msgpack_c_cpp-3.1.1-1 to 3.2.0-2 from repository HaikuPorts
    upgrade package msgpack_c_cpp_devel-3.1.1-1 to 3.2.0-2 from repository HaikuPorts
Continue? [yes/no] (yes) : y
100% msgpack_c_cpp-3.2.0-2-x86_64.hpkg [13.43 KiB]
(...)
[system] Done.

予想外に良い。 それは私が言ったことですか？

元の問題に戻ります。

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

彼らは、Haiku の 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

プロフィールだけでも同じです。 Googleで検索して、 これを見つけました。 追加すると -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

「Bad port 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!

本当にシンプルです。 一分未満！

haikuporter と haikuports を使用して hpkg でアプリケーションをパッケージ化します。

何から始めればよいでしょうか? 簡単なドキュメントはありません。irc.freenode.net の #haiku チャンネルにアクセスして、次のことを聞きます。

• チーム package - パッケージを作成する低レベルの方法。 「適切な .hpkg パッケージへの作成」セクションで説明されているように、ほとんどの場合、PackageInfo で十分です。
• 何かをしなければなりません такое
• 使用できます hpkgクリエーター （私にとってはクラッシュします、 エラー報告)

何をすべきかは明確ではありません。 Hello World スタイルの初心者ガイド、理想的にはビデオが必要だと思います。 GNU hello で行われているように、HaikuPorter の便利な紹介もあればよいでしょう。

私は以下を読んでいます：

haikuporter Haiku の共通パッケージ プロジェクトを作成するためのツールです。 すべてのパッケージのベースとして 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。 リポジトリ内のすべてのパッケージの依存関係がチェックされます 俳句ポート、少し時間がかかります。 コーヒーを飲みに行きます。

一体なぜこのチェックをサーバー上で全員に 1 回ずつ集中的に行うのではなく、私のローカル マシン上で実行する必要があるのでしょうか?

氏によれば、 よちよちスプラッシュ:

これにより、リポジトリ内の任意のファイルを書き換えることができます 😉 最後に行われた変更は非常にまれであるため、必要なときに必要な情報を計算して、これを少し最適化できます。

~/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 コミットと一致しますか? (開発者は「それは機能しません。レシピは比較的安定するように設計されています。」と認めています。)

楽しみのために、レシピに以下を追加してください。

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 は安全ではありません！）と叫びながら、まだ何かを解凍しようとしているのでしょうか。

による 氏。 よちよちスプラッシュ:

そうですね、その理由は、組み立てのために受け取ったデータの整合性をチェックしたいという要望でした。 オプションの XNUMX つはアーカイブのチェックサムを検証することですが、もちろん、個々のファイルをハッシュすることもできますが、これは実装されません。 もっと時間がかかります。 この結果、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 ネットワークの #haiku チャンネルで良い人たちに質問をしています。 そして、彼らなしでは私はどこにいるでしょうか？ ヒントの後、次のものを使用する必要があることに気付きました。

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

さて、これが何をするのかが明らかになりました。特定のリビジョンのソース コードを含むアーカイブをダウンロードします。 私の観点からすると、それは愚かなことですし、私が望んでいたもの、つまり master ブランチから最新リビジョンをダウンロードすることとはまったく違います。

開発者の一人はそれを次のように説明しました。

私たちは独自の 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 の使用で気に入っている点がいくつかあります。 ほとんどの場合、これは Linux ビルドを構築するためのツール セットである Open Build Service に似ています。体系的なアプローチを備えた非常に強力ですが、私の小さな「Hello World」アプリケーションには過剰すぎます。

繰り返しますが、氏によると、 よちよちスプラッシュ:

実際、HaikuPorter はデフォルトで非常に厳密です (さらに、これをさらに厳密にする lint モードと strict モードもあります!)。それは単にパッケージを作成するのではなく、機能するパッケージを作成するためです。 だからこそ、彼は宣言されていない依存関係、正しくインポートされていないライブラリ、間違ったバージョンなどについて不満を言っています。 目標は、将来の問題も含め、あらゆる問題をユーザーが知る前に検出することです (これが、avrdude をインストールできなかった理由です。依存関係が実際にはレシピで指定されていたためです)。 ライブラリは単なる個別のパッケージではなく、さらには特定の SO バージョンでもありません。 HaikuPorter は、実行中のエラーを回避するために、レシピ自体でこれらすべてが確実に監視されるようにします。

原則として、オペレーティング システムを作成する場合、このレベルの厳密さは正当化されますが、「Hello World」アプリケーションには不要であるように私には思えます。 他のことを試してみることにしました。

「package create」コマンドを使用して 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

このトリックはうまくいくと確信していますが、なぜこれが必要なのか、何のためにするのかという疑問が残ります。 これでは、システムが非常に洗練されているという全体的な印象が台無しになってしまうと思います。

氏の説明によると、 よちよちスプラッシュ:

場合によっては、他のアプリケーションが必要とするにもかかわらず、メニューにないアプリケーションが存在することがあります。 たとえば、スクリーンショットの LegacyPackageInstaller は、BeOS 形式で .pkg アーカイブを処理しています。 ユーザーにインストールしてもらいたいのですが、メニューに存在すると混乱が生じます。

何らかの理由で、もっと簡単な解決策があるように思えます。たとえば、 Hidden=true ファイル内 .desktop Linux 上で。 なぜ「隠された」情報をファイルシステムのリソースおよび属性にしてはいけないのでしょうか?

特に微妙なのは、メニューを表示する（いくつかの）アプリケーションの名前です。 deskbar、途中で固く結ばれます。

氏。 ワドルスプラッシュはこれについて次のように説明しています。

この場合の「デスクバー」は、一種の一般用語として理解する必要があります (Windows アプリケーションと一般的な概念の両方を指す「タスクバー」とほぼ同じです)。 さて、この後から deskbar「デスクバー」ではなく、これも同様に理解できます。

アプリケーションが含まれる 2 つの「ほぼ同一の」ディレクトリ

アプリケーションが含まれるディレクトリが 2 つあるのはなぜですか? また、QtQuickApplication が一方には存在し、もう一方には存在しないのはなぜですか? (結局のところ、これは XNUMX つのシステムのものではなく、XNUMX 番目のユーザーのものであり、個人的には理解できます)。
本当に混乱しているので、これは統一すべきだと思います。

氏のコメントよちよちスプラッシュ

アプリ カタログには、メニューには必要のないアプリケーションが含まれています。 しかし、メニューをよりカスタマイズしやすくするには、メニューの状況を改善する必要があります。

申請しないと実現しません 😉

アプリケーションをホストする必要があるのか​​と疑問に思いました。 /system/apps、ユーザーがそこにそれらを表示する場合、それは望ましくありません。 おそらく、ユーザーが遭遇しない別の場所にそれらを配置した方がよいでしょうか? Mac OS X で行われるのと同じように、パッケージの内容は .app、ユーザーには表示されないはずです /Applications、/System/Library/…の奥に隠れています。

依存関係についてはどうですか?

何らかの方法で依存関係を指定する価値があると思いますよね? Qt はデフォルトで Haiku インストールの必須部分とみなしてもよいでしょうか? いいえ！ Qtはデフォルトではインストールされていません。 パッケージ ビルダーは ELF ファイルをチェックして依存関係を自動的に検出できますか? HaikuPorter が実際にこれを行うと言われましたが、 package いいえ。 それは、単にファイルを勝手に作成するだけの「パッケージビルダー」だからです。 hpkg.

パッケージが Haiku の外部のパッケージに依存しないようにするというポリシーを追加して、Haiku をより洗練する必要がありますか? haikuports? (そのようなポリシーを使用すると、作業がはるかに簡単になるため、そうしたいと考えています。システムは、追加のパッケージ ソースをいじることなく、どこからでもダウンロードされたすべてのパッケージの依存関係を自動的に解決できるようになります。)

氏。 ワドルスプラッシュは次のように説明しています。

CompanyX が依存関係のある自社のソフトウェア セット (したがってリポジトリ) をサポートしたい場合は、完全に自由にサポートすることは明らかであるため、開発者の自由をそれほど制限したくありません。

その場合、サードパーティのパッケージがアプリケーションに必要なものすべてを完全にパッケージ化することで、haikuport に含まれていないものへの依存を回避することを推奨する価値があるかもしれません。 しかし、これはこのシリーズの将来の記事のトピックになると思います。 [作者はAppImageに向かっているのか？ — 約翻訳者]

アプリケーションアイコンの追加

新しく作成したアプリケーションのリソースに、きちんとした組み込みアイコンの XNUMX つを追加したい場合はどうすればよいでしょうか? これは素晴らしいトピックであることが判明したので、次の記事の基礎とします。

継続的なアプリケーションのビルドを整理するにはどうすればよいですか?

Inkscape のようなプロジェクトを想像してみてください (はい、Haiku ではまだ利用できないことは承知していますが、Haiku 上で表示すると便利です)。 彼らはソースコードリポジトリを持っています https://gitlab.com/inkscape/inkscape.
誰かが変更をリポジトリにコミットするたびに、ビルド パイプラインが起動され、その後、変更は自動的にテスト、ビルドされ、アプリケーションは AppImage for Linux (ローカル テスト用にダウンロードできるスタンドアロン アプリケーション パッケージ) などのさまざまなパッケージにパッケージ化されます。システムに何がインストールされるか、またはインストールされないか [私はそれを知っていた！ — 約翻訳者]）。 同じことがすべてのブランチ マージ リクエストで発生するため、マージ前にマージ リクエストで提案されたコードから構築されたアプリケーションをダウンロードできます。

ビルド ステータスとマージ リクエスト、およびビルドが成功した場合にコンパイルされたバイナリをダウンロードする機能 (緑色でマーク)

ビルドは Docker コンテナーで実行されます。 GitLab は Linux 上の無料のランナーを提供しており、独自のランナーを組み込むことも可能かもしれないと思います (ちなみに、これが Haiku のようなシステムでどのように機能するかわかりません。Haiku には Docker や同等のものがないのはわかっていますが、また、FreeBSD には Docker がないため、この問題は Haiku に固有のものではありません)。

理想的には、Haiku アプリケーションは Linux 用の Docker コンテナ内に構築できます。 この状況では、Haiku のアセンブリを既存のパイプラインに導入できます。 クロスコンパイラーはありますか? それとも、QEMU/KVM などを使用して Docker コンテナ内で Haiku をすべてエミュレートする必要がありますか (Docker 内でそのように動作すると仮定して)。 ちなみに、多くのプロジェクトが同様の原則を使用しています。 たとえば、Scribus はこれを実行します。これはすでに Haiku で利用可能です。 いつか送れる日が来るだろう そのような Haiku サポートを追加するには、他のプロジェクトにリクエストをプルします。

開発者の一人は次のように説明しています。

パッケージを自分で作成したい他のプロジェクトの場合は、通常の CMake/CPack メソッドがサポートされています。 他のビルド システムは、パッケージのビルド プログラムを直接呼び出すことでサポートできます。興味がある場合は問題ありません。 経験上、これまでのところあまり関心がなかったため、haikuporter は私たちにとって都合よく機能しましたが、最終的には両方の方法が連携して機能するはずです。 Linux またはその他のサーバー オペレーティング システムからソフトウェアをクロスビルドするためのツール セットを導入する必要があります (Haiku はサーバー上で実行するように設計されていません)。

私はスタンディングオベーションを送ります。 通常の Linux ユーザーは、サーバー オペレーティング システムには必要ですが、個人のオペレーティング システムには必要ない、このような追加の負荷と追加の荷物 (セキュリティ、厳格な管理など) をすべて背負っています。 したがって、Linux 上で Haiku アプリを構築できることが最善の方法であるということに完全に同意します。

まとめ

POSIX アプリケーションを Haiku に移植することは可能ですが、通常の再構築よりも高価になる可能性があります。 irc.freenode.net ネットワークの #haiku チャンネルの人々の助けがなかったら、私は間違いなく長い間この問題に行き詰まっていたでしょう。 しかし、彼らですら、何が問題なのかすぐにわかるとは限りませんでした。

Qt で書かれたアプリケーションは簡単な例外です。 簡単なデモアプリケーションを問題なく組み立てました。

単純なアプリケーション用のパッケージを構築することも非常に簡単ですが、それは「伝統的にリリースされた」アプリケーションのみに限られます。 haikuports でのサポートを目的としたバージョン管理されたソース コード アーカイブを持っています。 GitHub を使用した継続的なビルド (変更のコミットごとにビルド) の場合、すべてがそれほど単純ではないようです。 ここでの Haiku は、Mac での結果よりも Linux ディストリビューションのように感じられます。XCode で「Build」ボタンをクリックすると、パッケージが取得されます。 .app、ディスクイメージに挿入する準備ができています .dmg、私のウェブサイトでダウンロードできるように準備されています。
Linux などの「サーバー」オペレーティング システムに基づくアプリケーションの継続的な構築は、開発者からの需要があればおそらく可能になるでしょう。しかし現時点では、Haiku プロジェクトには別のより差し迫ったタスクがあります。

あなたも試してみてください！ 結局のところ、Haiku プロジェクトは、DVD または USB から起動するためのイメージを提供します。 日々。 インストールするには、イメージをダウンロードし、次のコマンドを使用して USB フラッシュ ドライブに書き込むだけです。 エッチャー

質問がありますか? ロシア語圏へご招待します 電報チャンネル.

エラーの概要: C および C++ で自分の足を撃つ方法。 Haiku OS レシピ集

から 作者 翻訳: これは俳句に関するシリーズの XNUMX 番目の記事です。

記事一覧： 最初の 2番目 Третья 4番目

出所： habr.com