Bug#884798: lintian could complain about pkg-config uses that fail to use $ac_tool_prefix

[Helmut Grohne <helmut@subdivi.de>]

Package: lintian
Severity: wishlist
User: helmutg@debian.org
Usertags: rebootstrap

Hi lintian developers,

I would like to discuss a potentially new tag. If this makes sense, I'd
hope that someone can turn it into code. If not, please close as
wontfix.

After sending like 1000 cross build patches, I can tell that wrong use
of pkg-config in autotools projects is common and poses a significant
fraction of said patches. The common theme is some upstream is using

    AC_PATH_PROG(PKG_CONFIG, pkg-config, no)

or some variant of it in its configure.ac or configure.in. This causes
PKG_CONFIG to be initialized to pkg-config. A later PKG_CHECK_MODULES
will pick up this value rather than ${ac_tool_prefix}pkg-config. Using
the wrong pkg-config typically results in cross builds failing to find
.pc files. This is common.

A slightly better way would be using AC_PATH_TOOL (with the same
arguments) and the only difference here is considering $ac_tool_prefix.
The recommended way is using the PKG_PROG_PKG_CONFIG macro from
pkg-config tough. This macro will result in an empty PKG_CONFIG variable
if pkg-config happens to not be found rather than the "no" value
depicted above.

Some configure.ac and configure.in use plain pkg-config directly and
this tends to be broken as well. The immediate fix often is inserting
soe PKG_PROG_PKG_CONFIG and then using $PKG_CONFIG rather than
pkg-config.

Of course this is an upstream-only tag, and
https://codesearch.debian.net/search?q=AC_PATH_PROG.*pkg-config
shows just how common it is. Would this be suitable for a lintian tag?

If yes, what would be a good check? Should it just check the toplevel
configure.ac and configure.in or any file found on any directory level?
Should it just complain about the typical

    AC_PATH_PROG\s*\(\s*\[?\s*\S*\s*\]?\s*[A-Z_]+\s*\[?\s*pkg-config\s*[,)]

or rather simply flag any use of pkg-config? The latter would cover the
correct but not very idiomatic

    AC_PATH_TOOL(PKG_CONFIG, pkg-config, no)

as well. Potentially flagging

    (\$\(|`)pkg-config

may help to catch the hard coded variants. I haven't performed a whole
archive-analysis yet, so I cannot tell about the amount of fpos to be
expected.

Let me also help draft a tag description:

    The package uses AC_PATH_PROG to discover pkg-config. This macro
    fails to select the correct pkg-config for cross compilation. A
    better macro for discovering pkg-config is PKG_PROG_PKG_CONFIG from
    pkg.m4.

And for the other case maybe:

    The package directly invokes pkg-config without considering an
    architecture prefix ($ac_tool_prefix) for cross compilation. A
    better way would be discovering the correct pkg-config using
    PKG_PROG_PKG_CONFIG from pkg.m4 and then using the shell variable
    $PKG_CONFIG.

These are up for your improvements of course.

Looking forward to your feedback.

Helmut