PKG_CHECK_MODULES被认为有害吗? [英] PKG_CHECK_MODULES considered harmful?

问题描述

各种开发人员不鼓励使用PKG_CHECK_MODULES(例如，在此答案中)，但目前尚无定论. ，就我所寻找的原因进行全面的解释.所以，我问:

Various developers discourage the usage of the PKG_CHECK_MODULES (for example, in this answer) but there is no clear, comprehensive explanation of their reasons as far as I've looked for. So, I ask:

• PKG_CHECK_MODULES为什么有害?
• 有哪些替代方案?

• Why would PKG_CHECK_MODULES be harmful?
• What are the alternatives?

我今天第一次使用它.我发现它非常有用，特别是在处理非常复杂的库集(例如GTK +)时，它具有所有这些依赖性:

I, for one, used it for the first time today. I found it invaluably useful, specially for dealing with pretty intricate library sets, such as GTK+, where I have all these dependencies:

-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 

推荐答案

PKG_CHECK_MODULES的一个重要问题是，它会导致应该失败的地方.如果用户在/p/a/t/h中安装了libfoo并使用LDFLAGS=-L/p/a/t/h调用了configure脚本，则该用户有理由期望配置找到libfoo.但是，用户还必须设置PKG_CONFIG_PATH，以便configure脚本可以找到foo.pc，以使配置成功，并且我认为这是无效的.可能会调用AC_CHECK_LIB，然后仅在通过标准机制找不到该库的情况下才调用PKG_CHECK_MODULES，以避免该问题.另一个问题是，PKG_CHECK_MODULES完全有可能在其中找到信息不正确的.pc文件，从而导致构建失败.在这种情况下，必须在PKG_CHECK_MODULES之后调用AC_CHECK_LIB.

One significant problem with PKG_CHECK_MODULES is that it causes failures where it should not. If a user installs libfoo in /p/a/t/h and invokes a configure script with LDFLAGS=-L/p/a/t/h, the user is justified in expecting the configury to find libfoo. But, the user also must set PKG_CONFIG_PATH so that the configure script can find foo.pc in order for the configury to succeed, and in my opinion that is broken. It would be possible to invoke AC_CHECK_LIB and then only invoke PKG_CHECK_MODULES if the library is not found through the standard mechanism to avoid that problem. Another issue is that it is entirely possible for PKG_CHECK_MODULES to find a .pc file in which the information is inaccurate, causing the build to fail. In that case, it is necessary to invoke AC_CHECK_LIB after PKG_CHECK_MODULES.

简而言之，要正确使用PKG_CHECK_MODULES，必须先调用AC_CHECK_LIBS，然后有条件地调用PKG_CHECK_MODULES，然后再次调用AC_CHECK_LIBS，以验证PKG_CHECK_MODULES找到的信息.维护者方面的所有这些额外工作只是使用户更容易在非标准位置安装它们的库，这是荒谬的.用户应建立他们的工具链，以通过标准机制查找库.

In short, to use PKG_CHECK_MODULES correctly, it is necessary to invoke AC_CHECK_LIBS first, then conditionally invoke PKG_CHECK_MODULES, and then invoke AC_CHECK_LIBS again to validate the information found by PKG_CHECK_MODULES. All of this additional work on the part of the maintainer just to make it easier for users to install their libraries in non-standard location is absurd. The user should set up their tool chain to find libraries through the standard mechanisms.

-编辑-

为澄清起见，我不建议使用鼓励使用PKG_CHECK_MODULES的库的软件包应避免在其配置中使用它.相反，我建议库不要鼓励其使用并停止分发.pc文件.试图通过.pc文件解决的问题可以在更高级别上得到更好的解决.自动工具不是软件包管理系统，这是软件包管理工具应解决的问题.

To clarify, I am not suggesting that a package which uses a library which encourages the use of PKG_CHECK_MODULES should avoid using it in their configury. Rather, I am recommending that libraries not encourage its use and stop distributing .pc files. The problem that is trying to be solved by .pc files is better addressed at a higher level. The autotools are not a package management system, and this is a problem that should be addressed by a package management tool.

这篇关于PKG_CHECK_MODULES被认为有害吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！