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
.
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.
-- EDIT --
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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…