PKG_CHECK_MODULES_STATIC is a convenience autoconf macro wrapping
PKG_CHECK_MODULES with --static enabled. This gives developers a way to
get static linking information from a specific set of modules.
Freedesktop #19541 (https://bugs.freedesktop.org/show_bug.cgi?id=19541)
Normally, the parser will exit immediately when it encounters errors in
.pc files. This is good most of the time, but for --list-all, the
purpose is to just get a quick list of packages and not to validate .pc
files. This is especially the case for pkg-config wrappers such as the
Ruby or Bash completion modules that scrape the output from --list-all
and don't expect to encounter errors there.
Freedesktop #26615 (https://bugs.freedesktop.org/show_bug.cgi?id=26615)
When listing all packages, the purpose is to get a quick look at what's
installed and not to scrutinize the validity of each .pc file. To see
errors from the parser during --list-all, the user can just add
--print-errors.
Upstream rpm has some convenience inline functions for strcmp and the
character class functions. Define some macros here to make our code look
more like upstream despite being the same functionally.
One difference noted while investigating the inline functions in
upstream is that the rpm character class functions are slightly
different from the standard functions. The rpm functions are independent
of locale, unlike the libc routines. pkg-config should probably do the
same and could easily use the g_ascii_is* macros from glib.
strcmp is only guaranteed to return !0 when the strings are unmatched
while rpmvercmp says it will return only -1 or 1 in those cases.
pkg-config currently only checks for !0, so this doesn't actually fix
any issues here. However, this is harmless and helps minimize the diff
with upstream rpmvercmp.
http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=ee64849e
The rpmvercmp code is taken directly from upstream. Moving it to a
separate file allows it to be diffed and synced easily with the upstream
version. It also becomes really easy to switch to the actual rpmlib
version if that's ever desired.
Exercise the ${pcfiledir} and --define-prefix features for allowing
relocation of packages. The --define-prefix test .pc files are put in a
pkgconfig subdirectory since the feature will only be enabled in that
situation.
Define all the autoconf build directories besides srcdir, which is
required to run the test scripts and set by "make check", and builddir,
which is always assumed to be ".".
The derived variables pcfiledir, pc_top_builddir and pc_sysrootdir were
lacking in documentation. Rework the "QUERYING PKG-CONFIG'S DEFAULTS"
section to describe these and pc_path.
The example of using "pkg-config --modversion pkg-config" was removed
since it's superfluous to "pkg-config --version".
Freedesktop #62018 (https://bugs.freedesktop.org/show_bug.cgi?id=62018)
Allowing pkg-config to override the prefix variable in .pc files is a
useful feature for making packages relocatable. There's nothing Windows
specific about it.
Freedesktop #63602 (https://bugs.freedesktop.org/show_bug.cgi?id=63602)
The prefix redefinition feature on Windows to make packages relocatable
was being confined only to locations where the .pc file was in a
directory ending in lib/pkgconfig or share/pkgconfig. This is too
restrictive as it's quite common for the libdir to have a different name
such as lib64. This keeps the convention that the feature will only be
enabled when the .pc file is in a pkgconfig directory, and it continues
to define the prefix to the grandparent of the pkgconfig directory.
The path handling is switched over to standard glib functions
g_path_get_basename and g_path_get_dirname to avoid handrolled handling
of Windows paths.
Currently the native Win32 builds default to redefining the prefix
variable in .pc files based on their installation paths. This behavior
is not always desired when pkg-config is being used in a traditional
fixed path environment (e.g., /mingw like /usr).
Allow the default to be set via configure switch
--enable/disable-define-prefix, and allow it to be set both ways at
runtime through the --[dont-]define-prefix pkg-config option.
Commit 9bf6277b reworked how Libs arguments are parsed but unfortunately
added an extra library suffix component into -L arguments. This only
affects MSVC syntax where the suffix is .libs. All other platforms use a
blank suffix in linker commands.
MSYS mangles UNIX paths on execution such that it prepends its root in
Windows format. This affects PKG_CONFIG_SYSROOT_DIR and thus the
check-sysroot test. Detect MSYS from the OSTYPE environment variable and
adjust the expected test results to match. This likely means that
sysroot support doesn't actually work on MSYS, but there probably aren't
any toolchains that support sysroot there, anyway.
When printing warnings on stderr that don't immediately exit pkg-config,
flush it so that the messages appear in order with stdout. This is
mostly to keep the test suite passing on Windows where output may appear
differently than on Linux.
When check-path is run on native Windows (MINGW), that path reported
by `pkg-config --variable=pc_path pkg-config` is adjusted to the
directory pkg-config is run from. Adjust the expected result based on
getting the current directory from cmd in Windows format.
The host triplet describes the machine the program will run on while the
build triplet describes the machine the program is being built on. The
determination of native Win32 should be based on where pkg-config is
going to be running. This makes pkg-config cross-compiled for windows
work as if it was built on windows.
By using our PKG_CHECK_MODULES from our in-tree pkg.m4, the check for
glib will be done the same way pkg-config is used everywhere else. This
includes the usage of AC_PATH_TOOL in PKG_PROG_PKG_CONFIG, which will
check for $host-pkg-config when --host is set during configure.
Freedesktop #59435 (https://bugs.freedesktop.org/show_bug.cgi?id=59435)
Instead of keeping of list of packages in the current Requires chain and
searching it repeatedly, just mark each package as part of the chain or
not. This nearly cuts in half the time on a particularly rough torture
test I have.
When the basename of the libdir is lib64, we currently add the paths
/usr/lib64:/lib64 to the generic system library path of /usr/lib:/lib.
Extend this coverage to other valid ABIs that use libdirs such as lib32
or libx32.
The intention was that errors would be printed for all output options
besides --exists and --atleast/exact/max-version, which are intended to
operate silently. Since want_exists is always set for these latter
options, we can simply use that as the condition and catch all other
output options automatically.
Freedesktop #54390 (https://bugs.freedesktop.org/show_bug.cgi?id=54390)
This provides the user with output matching the behavior of the code.
When multiple --atleast/exact/max-version options are supplied, only the
first will be honored.
The --atleast/exact/max-version help description implied that it would
return as --exists does. However, this would only occur if no other
output options were set.
Freedesktop #54389 (https://bugs.freedesktop.org/show_bug.cgi?id=54389)
This happened basically by accident before when "pkg-config foo" was run
because the code wouldn't find any options set and just fall through to
the end after processing the package arguments. However, it would act
differently in that Requires.private was only enabled with an explicit
--exists.
Currently, any output option (e.g., --version or --libs) will be set as
valid and what's output is at the mercy of the order of the output
handling code in main(). However, most combinations of output would make
no sense to be used together. For example, mixing --modversion and
--print-provides provides no way to differentiate between the output
from the options. Further, mixing --variable and --cflags currently
causes an error because there's no space separating the option outputs.
Instead, keep track of when an output option has been set and ignore
subsequent output options. There are currently two exceptions:
1. Any combination of --cflags* and --libs* are allowed.
2. Both --print-requires and --print-requires-private can be used
together as the user may just not care which is private.
Freedesktop #54391 (https://bugs.freedesktop.org/show_bug.cgi?id=54391)
With the output options gathered in a callback, we can be more clever
with the --cflags/--libs options and set the flags mask straight off
without using the intermediate booleans.
The code handling processing of the packages from the command line was
in an awkward block in main. Split it out to a separate function to keep
main mostly about output.
Having the option entries within main and requiring the option variables
to be static is just wrong. Just declare them at file scope like every
other program does.
