「Makepkg」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
447行目: 447行目:
   
 
これらのいずれかで問題が修正された場合、問題の原因となっているフラグを正確に特定すれば、アップストリームでバグを報告できる可能性があります。
  
これらのいずれかで問題が修正された場合、問題の原因となっているフラグを正確に特定すれば、アップストリームでバグを報告できる可能性があります。
−  
−
=== システムが使用できないほど遅くなる ===
  
−  
−
==== systemd コントロールグループでの makepkg の実行 ====
  
−  
−
ビルドしているパッケージが、デフォルトの ''make'' フラグ (他のほとんどのパッケージでは適切に設定されている) を使用してビルドするには多くのリソースを必要とします、そのパッケージを独自の [[cgroups|コントロールグループ]] で実行してみて下さい。{{AUR|makepkg-cg}} は、systemd コントロール グループを介してこれを実現する makepkg のラッパーです ({{man|5|systemd.resource-control}} を参照)
  
   
 
== 参照 ==
  
== 参照 ==

2024年10月20日 (日) 03:47時点における版

関連記事

makepkg はパッケージのビルドを自動化するスクリプトです。makepkg スクリプトを使用するにはビルドができる Unix プラットフォームと PKGBUILD が必要です。

makepkg は pacman パッケージの中に入っています。

目次

設定

makepkg の設定オプションについて詳しくは makepkg.conf(5) を参照してください。

/etc/makepkg.conf が makepkg のメインの設定ファイルです。ユーザー個別の設定は $XDG_CONFIG_HOME/pacman/makepkg.conf または ~/.makepkg.conf で可能です。パッケージをビルドする前に makepkg の設定オプションを微調整するとよいでしょう。

パッケージ作成者の情報

パッケージにはメタデータが付与されておりパッケージ作成者を識別することができます。デフォルトでは、ユーザーがコンパイルしたパッケージは Unknown Packager となります。システム上の複数のユーザーがパッケージをコンパイルする場合、あるいはパッケージを他者に配布する場合、実際の連絡先を入力すると便利です。makepkg.conf の PACKAGER 変数で設定することができます。

インストールしたパッケージの作成者情報を確認するには: 

$ pacman -Qi package
[...]
Packager       : John Doe <john@doe.com>
[...]

生成したパッケージに自動的に署名するには makepkg.conf で GPGKEY 変数を設定してください。

パッケージの出力

デフォルトでは makepkg はパッケージ tarball を作業ディレクトリに作成し、ソースデータを src/ ディレクトリに直接ダウンロードします。カスタムパスを設定することで、例えばビルドしたパッケージを ~/build/packages/ に、ソースを全て ~/build/sources/ に保存することができます。

必要に応じて以下の makepkg.conf 変数を設定してください:

  • PKGDEST — 生成したパッケージを保存するディレクトリ。
  • SRCDEST — ソース データを保存するディレクトリ (別の場所を指定すると src/ へのシンボリックリンクが作成されます)
  • SRCPKGDEST — 生成したソースパッケージを保存するディレクトリ (makepkg -S でビルド)
ヒント: PKGDEST ディレクトリのキャッシュを削除する方法は pacman#パッケージキャッシュの削除 を参照してください。例: paccache -r -c ~/build/packages/

署名チェック

ノート: makepkg で実装されている署名チェックは pacman のキーリングを使用しません [1] 代わりにユーザーのキーリングが使われます。

.sig または .asc の形式の署名ファイルが PKGBUILD ソース配列の一部である場合、makepkg は自動的に 検証 を試みます。ユーザーのキーリングに署名の検証に必要な公開鍵が含まれていない場合、makepkg は PGP 鍵を検証できなかったというメッセージを表示してインストールを中止します。

パッケージに必要な公開鍵が欠落している場合、PKGBUILD には必要な鍵 ID を持つ validpgpkeys エントリが含まれている可能性が高くなります。その場合手動で インポート 、または 鍵サーバー上 で見つけてそこからインポートします。署名チェックを一時的に無効にするには、--skippgpcheck オプションを指定して makepkg を実行します。

使用方法

続行する前に、base-devel グループを インストール してください。このグループに属するパッケージは、PKGBUILD ファイルでビルド時の依存関係 (makedepends) としてリストする必要はありません。

ノート:
  • pacman に渡されるコマンドに対して sudo が適切に設定されていることを確認してください。
  • makepkg 自体を root として実行することは 許可されていません.[2] PKGBUILD に任意のコマンドが含まれる可能性があることに加えて、root としてビルドすることは一般的に安全ではないと考えられています。[3] 通常のユーザー アカウントにアクセスできないユーザーは、nobody user として makepkg を実行する必要があります。

パッケージをビルドするには、パッケージの作成 で説明されているように、まず PKGBUILD またはビルド スクリプトを作成する必要があります。既存のスクリプトは、Arch Build System (ABS) ツリーまたは AUR から入手できます。 PKGBUILD を取得したら、それが保存されているディレクトリに移動し、次のコマンドを実行してパッケージをビルドします。 

$ makepkg

必要な依存関係が欠落している場合、makepkg は失敗する前に警告を発します。パッケージをビルドして必要な依存関係をインストールするには、フラグ -s/--syncdeps を追加します。 

$ makepkg --syncdeps

-r/--rmdeps フラグを追加すると、makepkg は後で不要になった make 依存関係を削除します。常にパッケージをビルドしている場合は、Pacman ヒント#使用していないパッケージ (孤立したパッケージ) の削除 を時々使用することを検討してください。

ノート:
  • これらの依存関係は、構成されたリポジトリで利用可能である必要があります。詳細は pacman#リポジトリとミラー を参照してください。または、ビルドの前に依存関係を手動でインストールすることもできます (pacman -S --asdeps dep1 dep2)
  • 依存関係をインストールするときは、グローバル値のみが使用されます。つまり、分割パッケージのパッケージング関数で行われたオーバーライドは使用されません。

すべての依存関係が満たされ、パッケージが正常にビルドされると、パッケージファイル (pkgname-pkgver.pkg.tar.zst) が作業ディレクトリに作成されます。インストールするには、-i/--install を使用します (pacman -U pkgname-pkgver.pkg.tar.zst): 

$ makepkg --install

$srcdir に抽出されたファイルなど、残りのファイルとディレクトリをクリーンアップするには、オプション -c/--clean を追加します。これは、同じビルド ディレクトリを使用しながら、同じパッケージの複数のビルドやパッケージバージョンの更新に役立ちます。古いファイルや残りのファイルが新しいビルドに引き継がれるのを防ぎます。 

$ makepkg --clean

詳細については、makepkg(8) を参照してください。

最適化

デフォルトのオプションは、devtools が 公式リポジトリ のパッケージを構築するために使用するオプションと一致します。[4] したがって、エンドユーザーは、ローカル環境に合わせて次のオプションを微調整することで、多かれ少なかれ大きなメリットを実感できる可能性があります。

パフォーマンス関連の変更

Commit 90bf367e (pacman 6.0.2-9 2024年2月から) ローカル パッケージのビルド パフォーマンスに重要な影響を与える可能性がある 2 つの設定変更が実装されており、特にユーザーによるレビューが推奨されます。:

ノート: 圧縮レベルの変更は、2024-08-16 [5] のコミット 319671cc で元に戻され、pacman 7.0 でロールアウトされます。[6]

さらに詳しいコンテキストについては、Archlinux/packaging/packages/pacman!1 および archlinux/packaging/packages/pacman#23 を参照してください。

最適化されたバイナリの構築

makepkg のデフォルトでは、様々なマシンでインストールできるような一般的なパッケージを生成するようにオプションが設定されています。ホストマシンにあわせてコンパイラの最適化を有効化することで、パッケージ化するソフトウェアの性能を向上させることができます。ただし特定のプロセッサアーキテクチャにあわせてパッケージをコンパイルした場合、他のマシンでは正しく動作しなくなります。x86_64 のマシンでは、時間を投資して公式のパッケージをリビルドすることでそれに見合うだけのパフォーマンスの向上を得られることは稀です。

標準外のコンパイラフラグを使うことでパフォーマンスが劣化する可能性も十分あります。ほとんどのコンパイラオプションは特定の状況でのみ有効であり、無差別に全てのパッケージに適用しないほうが良いでしょう。何かが速くなると確認・ベンチマークできない限り、無駄にコンパイラオプションを使わないことを推奨します。Gentoo の コンパイル最適化ガイド や 安全な CFLAGS 記事にはコンパイラの最適化に関する詳しい解説が載っています。

C/C++ コンパイラ (例: gcc や clang) に渡されるオプションは CFLAGS, CXXFLAGS, CPPFLAGS 環境変数で制御されます。同じように make ビルドシステムは MAKEFLAGS を使います。Arch のビルドシステムでは makepkg.conf の設定オプションとして makepkg はこれらの環境変数を使用します。デフォルト値は幅広いマシンにインストールできる汎用のパッケージを作成するように設定されています。

ノート:
  • すべてのビルドシステムが makepkg.conf で設定された変数を使用するわけではないことに注意してください。たとえば、cmake はプリプロセッサオプション環境変数 CPPFLAGS を無視します。したがって、多くの PKGBUILD には、パッケージ化されたソフトウェアで使用されるビルドシステムに固有のオプションを使用した回避策が含まれています。
  • Makefile のソースコードまたはコンパイルコマンドラインの特定の引数で指定された設定が優先され、makepkg.conf の設定がオーバーライドされる可能性があります。

GCC はアーキテクチャ固有の最適化を自動で認識・有効化することができます。自動最適化を使用するには、-march と -mtune フラグを全て削除してから -march=native を追加してください。例: 

/etc/makepkg.conf
CFLAGS="-march=native -O2 -pipe ..."
CXXFLAGS="${CFLAGS} ..."

march=native フラグによってどのフラグが有効になるのか確認するには、次のコマンドを実行してください: 

$ gcc -march=native -v -Q --help=target
ノート: -march=native 以外の値を指定した場合、-Q --help=target は期待通りに機能しなくなります [7] どのオプションが実際に有効になるのかはコンパイルを行わないと分かりません。詳しくは Gentoo wiki の Gentoo:Safe CFLAGS#Manual を参照して下さい。

pacman バージョン 5.2.2 以降、makepkg.conf には、Rust コンパイラに与えられるフラグの RUSTFLAGS 環境変数のオーバーライドも含まれています。Rust コンパイラは、指定された RUSTFLAGS 値に -C target-cpu=native を追加することで、アーキテクチャ固有の最適化を検出して有効にすることもできます。 

/etc/makepkg.conf
RUSTFLAGS="-C opt-level=2 -C target-cpu=native"

これにより有効になる CPU 機能を確認するには、次のコマンドを実行します。 

$ rustc -C target-cpu=native --print cfg

-C target-cpu=native を指定せずに --print cfg を実行すると、デフォルトの設定が出力されます。opt-level パラメータは、必要に応じて、3、s、または z に変更できます。詳細については、Rust コンパイラのドキュメント を参照してください。

ビルド時間を短縮する

並列コンパイル

make ビルドシステムは、MAKEFLAGS 環境変数 を使用して、make の追加オプションを指定します。 変数は、 makepkg.conf ファイルでも設定できます。

マルチコア/マルチプロセッサシステムを使用しているユーザーは、同時に実行するジョブの数を指定できます。 これは、 nproc を使用して使用可能なプロセッサの数を決定することで実現できます。 MAKEFLAGS="-j $(nproc)" 一部の PKGBUILD は、特定のバージョンの競合状態のため、または単に最初からサポートされていないため、これを -j1 で具体的にオーバーライドします。 このためにビルドに失敗したパッケージは、エラーが実際に発生していることを確認した後、バグトラッカー(またはAURパッケージの場合はパッケージメンテナ)に 報告 して下さい MAKEFLAGS が原因です。

使用可能なオプションの完全なリストについては、 make(1) を参照してください。

メモリ内のファイルからビルドする

コンパイルには多くの I/O 操作と小さなファイルの処理が必要なため、作業ディレクトリを tmpfs に移動すると、ビルド時間が早くなる可能性があります。

BUILDDIR 変数を一時的に makepkg にエクスポートして、ビルドディレクトリを既存の tmpfs に設定できます。例えば: 

$ BUILDDIR=/tmp/makepkg makepkg

永続的な設定は、デフォルトの /etc/makepkg.conf ファイルの BUILDENVIRONMENT セクションの最後にある BUILDDIR オプションのコメントを外すことで行うことができます。この値をたとえば BUILDDIR=/tmp/makepkg に設定すると、 Arch のデフォルトの /tmp テンポラリ・ファイル・システムが使用されます。

ノート:
  • メモリ不足を防ぐために、 tmpfs で大きなパッケージをコンパイルすることは避けてください。
  • tmpfs フォルダーは、 noexec オプションなしでマウントする必要があります。そうしないと、ビルドされたバイナリが実行されなくなります。
  • tmpfs でコンパイルされたパッケージは、再起動後も保持されないことに注意してください。 PKGDEST オプションを適切に設定して、ビルドされたパッケージを永続ディレクトリに自動的に移動することを検討してください。

コンパイルキャッシュの使用

ccache を使うことでコンパイル結果をキャッシュしてビルド時間を短縮できます。

mold linker の使用

mold は、ld/lld リンカーのドロップイン代替品であり、大幅に高速化されていると主張しています。

mold を使用するには、-fuse-ld=mold を LDFLAGS に追加します。例えば: 

/etc/makepkg.conf
LDFLAGS="... -fuse-ld=mold"

追加のオプションを mold に渡すには、それらを LDFLAGS に追加します。例えば: 

/etc/makepkg.conf
LDFLAGS="... -fuse-ld=mold -Wl,--separate-debug-file"

Rust パッケージに mold を使用するには、-C link-arg=-fuse-ld=mold を RUSTFLAGS に追加します。例えば: 

/etc/makepkg.conf
RUSTFLAGS="... -C link-arg=-fuse-ld=mold"

デバッグパッケージと LTO を無効にする

pacman 6.0.2-9 2024 年 2 月以降の pacman 6.0.2-9 に含まれる コミット 90bf367e では、デバッグオプションと lto オプションがデフォルトで有効になりました。

デバッグパッケージをビルドすると、公式リポジトリがユーザーの問題をトラブルシューティングするためのツールが提供できるようになります (archlinux.org/archlinux/packaging/packages/pacman/-/issues/23#note_173528) ただし、パッケージを独自にビルドする場合は必要なく、速度が低下します。ビルドプロセス archlinux.org/archlinux/packaging/packages/pacman/-/issues/23#note_173782 を参照してください。

Link-time optimization より最適化されたバイナリが生成されますが、ビルドプロセスが大幅に長くなります (archlinux.org/archlinux/packaging/packages/pacman/-/issues/23#note_173678) これらのオプションを無効にするには、! を追加します。 OPTIONS=() 配列の直前にある文字 (例: OPTIONS=(...!debug !lto...))

圧縮

他の圧縮アルゴリズムを使用する

パッケージ アーカイブが大きくなる代わりに、パッケージングとインストールの両方を高速化するには、PKGEXT を変更します。

たとえば、次の例ではパッケージ ファイルの圧縮がスキップされ、インストール で展開する必要がなくなります。 

$ PKGEXT='.pkg.tar' makepkg

別の例として、以下は速度に重点を置いた LZ4 アルゴリズムを使用しています。 

$ PKGEXT='.pkg.tar.lz4' makepkg

上記の設定を永続化するには /etc/makepkg.conf で PKGEXT を設定します。

マルチコアを利用して圧縮する

zstd は、 --threads フラグを介して 対称型マルチプロセッシング(SMP) をサポートし、圧縮を高速化します。たとえば、 makepkg がパッケージを圧縮するためにできるだけ多くの CPU コアを使用できるようにするには、/etc/makepkg.conf の COMPRESSZST 配列を編集します: 

COMPRESSZST=(zstd -c -z -q --threads=0 -)

xz は対称型マルチプロセッシング (SMP) による圧縮をサポートしています。--threads フラグを使うことで圧縮が高速化されます。例えば、makepkg でできる限り多くの CPU コアを使ってパッケージを圧縮するには、/etc/makepkg.conf の COMPRESSXZ 配列を編集: 

COMPRESSXZ=(xz -c -z --threads=0 -)

gzip の代替である並列実装の pigz はデフォルトで全ての CPU コアを使用します (-p/--processes フラグを使うことでコアの数を減らせます。) 

COMPRESSGZ=(pigz -c -f -n)

pbzip2は、 bzip2 のドロップイン並列実装であり、デフォルトで使用可能なすべての CPU コアも使用します。 -p# フラグを使用すると、使用するコアの数を減らすことができます(注: -p とコアの数の間にスペースは必要ありません。) 

COMPRESSBZ2=(pbzip2 -c -f)

lbzip2 は、デフォルトで利用可能なすべての CPU コアを使用する bzip2 の別のドロップイン並列実装です。-n フラグを使用すると、使用するコアを減らすことができます。 

COMPRESSBZ2=(lbzip2 -c -f)

plzipAUR は lzip のマルチスレッド実装であり、デフォルトで利用可能なすべての CPU コアも使用します。-n/--threads フラグを使用して、使用するコアを減らすことができます。 

COMPERSSLZ=(plzip -c -f)

圧縮レベルの変更

いくつかの圧縮アルゴリズム (zstd および xz を含む) は、速度、メモリ、圧縮効率の間のトレードオフを定義する圧縮レベルの設定をサポートしています。

ヒントとテクニック

ソースのダウンロードと抽出の時間を短縮する

ソースの場所の定義

特に VCSパッケージ をビルドするときに SRCDEST を利用すると、以降のリビルドでソースの取得や展開にかかる時間を短縮できます。

新しいチェックサムを生成する

PKGBUILD ファイルが存在するディレクトリと同じディレクトリで以下のコマンドを実行すれば新しいチェックサムが生成されます: 

$ updpkgsums

Windows の改行コード (\r\n) に注意してください。Git はテキストファイルに含まれている Windows の改行コードを UNIX の改行コード \n に置き換えるため、チェックサムが変わってしまいます。AUR のパッケージのチェックサムが検証できなかった場合、チェックサムを計算する前に以下のコマンドを使ってファイルの中から \r を取り除いてみてください: 

$ sed -i 's/\r//g' <filename>

ローカルのソースファイルからビルドする

ソース コードに変更を加えたい場合は、-o, --nobuild ファイルのみをダウンロードして抽出する オプションを使用すると、パッケージをビルドせずにソースコードをダウンロードできます。 

$ makepkg -o

これで、ソースに変更を加えてから、-e, --noextract ソースファイルを抽出しない (既存の $srcdir/ dir を使用) オプションを使用してパッケージをビルドできるようになりました。すでにビルドされているパッケージと既存のパッケージを上書きするには、-f オプションを使用します。 

$ makepkg -ef

特定のパッケージ作成者によるパッケージを表示

以下のコマンドはシステムにインストールされているパッケージの中から packagername という名前のパッケージ作成者によって作られたパッケージを全て表示します: 

$ expac "%n %p" | grep "packagername" | column -t

以下のコマンドは /etc/makepkg の PACKAGER 変数に設定されている値とパッケージ作成者が一致するパッケージを表示します (/etc/pacman.conf に定義されているリポジトリに含まれているパッケージだけが対象): 

$ . /etc/makepkg.conf; grep -xvFf <(pacman -Qqm) <(expac "%n\t%p" | grep "$PACKAGER$" | cut -f1)

64ビット環境で32ビットのパッケージをビルド

警告: この方法で linux パッケージをビルドしようとすると問題が発生するという報告があります。カーネルパッケージをビルドする場合は chroot を使用する方法を使うことを推奨します。

まず multilib リポジトリを有効にして multilib-devel をインストールしてください。gcc や gcc-libs パッケージを削除するかどうかきかれたら yes と答えてください。gcc-multilib は64ビットと32ビット両方のソフトウェアをビルドすることができます。

それから32ビットの設定ファイルを作成: 

~/.makepkg.i686.conf
CARCH="i686"
CHOST="i686-unknown-linux-gnu"
CFLAGS="-m32 -march=i686 -mtune=generic -O2 -pipe -fstack-protector-strong"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-m32 -Wl,-O1,--sort-common,--as-needed,-z,relro"

そして makepkg を以下のように実行してください: 

$ linux32 makepkg --config ~/.makepkg.i686.conf

署名の無いパッケージ

Jenkins などの自動ビルド環境で署名に使用される gpg 秘密鍵のパスフレーズを提供できる人がいない場合があります。パスフレーズなしでシステムに秘密の gpg キーを保存することはお勧めできません。

makepkg で作成された結果の zst パッケージは、作成後に署名することができます。 

$ gpg --detach-sign --pinentry-mode loopback --passphrase --passphrase-fd 0 --output NewlyBuilt.pkg.tar.zst.sig --sign NewlyBuilt.pkg.tar.zst

GPG パスフレーズは、選択したオートメーションスイートによって安全に提供され、隠蔽されます。

出来上がった zst と sig ファイルは有効な署名を期待する pacman クライアントや、あなた自身のリポジトリをホストするときに repo-add --sign で作成したリポジトリから参照することができます。

Magnet URIs

magnet:// のプレフィックスを持つ magnet URIs リソースのサポートは transmission-dlagentAUR ダウンロードエージェントを使って追加することができます。

systemd コントロールグループでの makepkg の実行

ビルドしているパッケージが、デフォルトの make フラグ (他のほとんどのパッケージでは適切に設定されている) を使用してビルドするには多くのリソースを必要とする場合は、そのパッケージを独自の コントロールグループ で実行してみて下さい。makepkg-cgAUR は、systemd コントロールグループを介してこれを実現する makepkg のラッパーです (systemd.resource-control(5) を参照)

アイドルスケジュールポリシーで実行

パッケージのビルドプロセスは、特に #並列コンパイル の場合に CPU 使用率が高くなる可能性があります。CPU 負荷が高い場合、nice(1) の値が最も高くても、システムの速度が大幅に低下し、使用できなくなる可能性があります。ユーザーインターフェイスとフォアグラウンドアプリケーションが途切れたり、応答しなくなったりすることがあります。

これは、makepkg を実行する前に、スケジューリングポリシーを SCHED_IDLE に変更することで回避できます。これにより、パッケージ構築プロセスが通常のタスクに干渉せず、残りの未使用の CPU 時間のみが利用されることが保証されます。

sched(7) § SCHED_IDLE: Scheduling very low priority jobs から:

このポリシーは、非常に低い優先度 (SCHED_OTHER または SCHED_BATCH ポリシーの +19 nice 値よりも低い) でジョブを実行することを目的としています。

SCHED_IDLE ポリシーは、-i フラグを指定して <codechrt>1 コマンドを実行し、優先度 0 (SCHED_IDLE の唯一の有効なオプション) を指定して設定できます。) を使用し、現在のシェルの PID を指定します。

ほとんどのシェルの場合: 

$ chrt -iap 0 $$
ヒント: このコマンドを makepkg.conf に置くことで、すべてのビルドに適用できます。

fish シェルの場合、$$ が設定されていない場合: 

$ chrt -iap 0 %self

各パッケージディレクトリ内の相対パス

パッケージ出力オプション に絶対パスを使用する代わりに、各パッケージディレクトリ内に相対パスを設定することもできます。

ノート: 次のオプションは、$startdir が定義されていないコンテキストで makepkg.conf を使用する可能性があるため、一部の AUR ヘルパー で問題を引き起こす可能性があります。

たとえば、次のように makepkg.conf ファイルでターゲットパスを定義できます。$startdir 変数は、パッケージをビルドするときに PKGBUILD が配置されるディレクトリを参照します。 

PKGDEST="$startdir/build/packages/"
SRCDEST="$startdir/build/sources/"
SRCPKGDEST="$startdir/build/srcpackages/"
LOGDEST="$startdir/logs/"

これにより、次のような結果が得られます。

  • ビルドされたパッケージは、"パッケージ ディレクトリ"/build/packages/ に保存されます。
  • ダウンロードされたすべてのソースファイルは、"パッケージ ディレクトリ"/build/sources/ に保存されます。
  • ビルドされたソースパッケージは、"パッケージ ディレクトリ"/build/srcpackages/ に保存されます。
  • すべてのログは、"パッケージ ディレクトリ"/logs/ に保存されます。

makepkg は通常どおりに src/ および pkg/ ディレクトリを作成するため、これは予期された動作です。

トラブルシューティング

QMAKE を使用するパッケージのインストールディレクトリを指定する

qmake によって生成される makefile は INSTALL_ROOT 環境変数を使ってプログラムをインストールするディレクトリを指定します。したがって package 関数を以下のようにしてください: 

PKGBUILD
...

package() {
	cd "$srcdir/${pkgname%-git}"
	make INSTALL_ROOT="$pkgdir" install
}

...

また、qmake を正しく設定する必要があります。例えば .pro ファイルに以下を記述してください: 

YourProject.pro
...

target.path = /usr/local/bin
INSTALLS += target

...

WARNING: Package contains reference to $srcdir

リテラル文字列 $srcdir か $pkgdir があなたのパッケージ内のインストールされたファイルのどれかに含まれています。

ファイルを確認するには、makepkg のビルドディレクトリから次のコマンドを実行してください: 

$ grep -R "$(pwd)/src" pkg/

詳しくは こちら を参照。

プロキシの背後にある時、makepkg は依存関係のダウンロードに失敗します

makepkg が依存関係を呼び出すと、 pacman を呼び出してパッケージをインストールします。これには、 sudo を介した管理者権限が必要です。ただし、 sudoは 環境変数を特権環境に渡さず、プロキシ関連の変数 ftp_proxy、 http_proxy、 https_proxy、 および no_proxy

プロキシの背後で makepkg を機能させるには、次のいずれかの方法を実行する必要があります。

XferCommand で URL を設定して、プロキシを有効にする

XferCommandは、 /etc/pacman.conf で目的のプロキシURLを使用するように設定できます。 pacman.conf [8] に次の行を追加するか、コメントを解除します。 

/etc/pacman.conf
...
XferCommand = /usr/bin/curl -x http://username:password@proxy.proxyhost.com:80 -L -C - -f -o %o %u
...

sudoer の env_keep を介してプロキシを有効にする

あるいは、sudoer の env_keep オプションを使用することもできます。これにより、特定の変数を特権環境に保持できます。詳細については、 sudo#環境変数 を参照してください。

makepkg は失敗するが、make は成功する

make を使用して手動でコンパイルできても、makepkg で失敗する場合、それはほぼ確実に /etc/makepkg.conf がコンパイル変数を通常は機能する合理的なものに設定されていますが、それは コンパイルしているものと互換性がありません。 これらのフラグを PKGBUILD options 配列に追加してみてください。

!buildflags、 デフォルトの CPPFLAGS、 CFLAGS、 CXXFLAGS、 および LDFLAGS を防ぐため。

!makeflags、 並列ビルドを有効にするために /etc/makepkg.conf を編集した場合に、デフォルトの MAKEFLAGS を防ぐため。

!debug、 デフォルトの DEBUG_CFLAGS を防ぐため、および DEBUG_CXXFLAGS (パッケージがデバッグビルドの場合)

これらのいずれかで問題が修正された場合、問題の原因となっているフラグを正確に特定すれば、アップストリームでバグを報告できる可能性があります。

参照

「https://wiki.archlinux.jp/index.php?title=Makepkg&oldid=39182」から取得