29

さまざまな開発者が の使用を思いとどまらせていますがPKG_CHECK_MODULES(たとえば、この回答では)、私が探した限り、その理由の明確で包括的な説明はありません。だから、私は尋ねます：

  • なぜPKG_CHECK_MODULES有害なのですか？
  • 代替手段は何ですか？

ちなみに私は今日初めて使いました。特に、GTK+ などの非常に複雑なライブラリ セットを扱う場合には、これらすべての依存関係があるため、非常に便利であることがわかりました。

-I/usr/lib/i386-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 
-I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 
-I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 
-I/usr/include/freetype2 -I/usr/include/libpng12

-lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 
-lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0
-lgthread-2.0 -lrt -lglib-2.0
4

2 に答える 2

27

の重大な問題の 1 つPKG_CHECK_MODULESは、本来あるべきではない場所で障害が発生することです。ユーザーが をインストールlibfooして を使用してスクリプトを/p/a/t/h呼び出す場合、ユーザーは構成が. ただし、ユーザーは、構成が成功するためにスクリプトが見つけることができるように設定する必要があります。私の意見では、それは壊れています。その問題を回避するために、ライブラリが標準メカニズムで見つからない場合にのみ、呼び出してから呼び出すことができます。もう 1 つの問題は、情報が不正確なファイルが見つかる可能性があり、ビルドが失敗する可能性があることです。その場合、 afterを呼び出す必要があります。configureLDFLAGS=-L/p/a/t/hlibfooPKG_CONFIG_PATHconfigurefoo.pcAC_CHECK_LIBPKG_CHECK_MODULESPKG_CHECK_MODULES.pcAC_CHECK_LIBPKG_CHECK_MODULES

つまり、PKG_CHECK_MODULES正しく使用するには、AC_CHECK_LIBSまず を呼び出し、次に条件付きで を呼び出しPKG_CHECK_MODULES、さらに を呼び出しAC_CHECK_LIBSて で見つかった情報を検証する必要がありPKG_CHECK_MODULESます。ユーザーがライブラリを非標準の場所に簡単にインストールできるようにするためだけにメンテナが行うこのような追加作業はすべてばかげています。ユーザーは、ツール チェーンをセットアップして、標準メカニズムを介してライブラリを検索する必要があります。

- 編集 -

明確にするために、使用を奨励するライブラリを使用するパッケージが構成で使用しないようにすることを提案しているわけではありませんPKG_CHECK_MODULES。むしろ、ライブラリがその使用を奨励せず、.pcファイルの配布を停止することをお勧めします。ファイルによって解決しようとしている問題は.pc、より高いレベルでより適切に対処されます。autotools はパッケージ管理システムではなく、これはパッケージ管理ツールで対処する必要がある問題です。

于 2012-04-19T14:05:04.610 に答える