The iteration order of GHashTable changed in GLib 2.59, which broke the
check-print-options test, as it relied on a fixed output order from the
--list-all argument to pkg-config.
Fix that by making print_package_list() output in alphabetical order by
Package.key; and update the test to match. This should work with older
and newer versions of GLib.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Treat -isystem and -idirafter as -I Cflags since they control the
compiler search path. Adjust the sysroot handling so that the arguments
to these options have the sysroot prefixed. However, leave them out of the
system Cflags handling since these directives are explicitly trying to
adjust the compiler's system header search behavior.
The special-flags test case output needs adjustment since all the flags
are now considered -I flags and come out in the order specified in the
pc file.
https://bugs.freedesktop.org/show_bug.cgi?id=97337
If the original prefix setting is empty, skip prepending the redefined
prefix to other variables. This works the same as if the pc file doesn't
have a prefix variable at all.
https://bugs.freedesktop.org/show_bug.cgi?id=97453-empty
Adds a hash table to the package list expansion to avoid iterating over
the children of package nodes that have already been visited. Without
this, the expansion is exponential. For library sets with a high degree
of dependency, iteration over the tree with revisiting results, in
practice, in significant slow down at best and pkg-config failure due to
memory exhaustion at worst. The resulting algorithm is equivalent to a
topological sort.
Add some more tests for handling unusual variables such as those that
are quoted or that contain shell characters. This should help make the
--variable output more reliable in the future.
https://bugs.freedesktop.org/show_bug.cgi?id=93284
pkg-config allows a way to override package variables through the
--define-prefix interface, but this is very cumbersome to do in a global
way since it always needs to be passed on the command line and the
override cannot be scoped to a single packge.
Allow overriding package variables using environment variables of the
form PKG_CONFIG_$PACKAGE_$VARIABLE. For example, setting
PKG_CONFIG_GLADEUI_2_0_CATALOGDIR will override the variable
"catalogdir" in the "gladeui-2.0" package.
https://bugs.freedesktop.org/show_bug.cgi?id=90917
Wine outputs the paths with carriage returns, which later breaks
commands they're used in. Hopefully this doesn't break the msys case,
but I think it should be safe enough. Really this needs general handling
of Windows paths instead of ad hoc fixes, but that's for another day.
https://bugs.freedesktop.org/show_bug.cgi?id=66939
Rather than responding to the pcfiledir variable specially, store it
in the hash table with all the other package specific variables. This
does result in pcfiledir showing up in the --print-variables output.
If a --variable is requested, make sure to remove the quoting since it's
likely the value will be used verbatim in shell command substitution. If
the quotes remain in the value, they'd get embedded in the shell
variable, too.
Freedesktop #67904 (https://bugs.freedesktop.org/show_bug.cgi?id=67904)
When pkg-config redefines the .pc file's prefix variable, it will be in
the platform's native format. Convert the expected results as
necessary. This only affects the relocatable test because it explicitly
sets --define-prefix or uses .pc files in a pkgconfig/ directory. Other
tests do not have their prefixes redefined for this reason.
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.
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 ".".
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 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 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)
pkg-config strips all duplicate arguments from the flag output string.
This is done for 2 reasons:
1. When a package shows up twice in the final package list after
resolving all Requires, stripping was used to ensure it's flags only
showed up once at the correct location.
2. An optimization so that the output string is not excessively long.
Since commit c6ec7869, 1. is no longer necessary as the final package
list only contains each package once. 2. causes problems when applied
too aggressively since some arguments have different semantics depending
on the prior or subsequent arguments.
To keep a bit of optimization, the stripping is reduced to only removing
consecutive duplicate arguments. This should ensure that the semantics
are kept intact while removing obviously unnecessary arguments.
The drawback is that some arguments will now appear multiple times in
the output when they previously would have only appeared once. Here we
have to rely on the tools using these arguments to handle the duplicates
appropriately since there is no way for pkg-config to encode all the
semantics of those arguments. Another thing that can help this situation
is if pkg-config is used for all packages in the Requires chain so that
the Libs/Cflags of each package only pertain to itself and don't encode
the compiling/linking rules of a 3rd party package.
Freedesktop #16101 (https://bugs.freedesktop.org/show_bug.cgi?id=16101)
Often other Libs flags have semantics that are based on their context
with -l arguments. For example, the GNU linker options
-Bdynamic/-Bstatic pertain only to the objects or link options that
follow them. So, a valid link command containing these options would get
mangled by pkg-config since it separates -l flags from others..
-Bdynamic -la -Bstatic -lb -> -Bdynamic -Bstatic -la -lb
Instead, output -l and other Libs flags in a single pass so they mantain
their ordering.
Freedesktop #19950 (https://bugs.freedesktop.org/show_bug.cgi?id=19950)
Outputting other Libs flags such as -Wl,foo just prior to the -l Libs
flags gives a better chance the --libs output will be correct. This
should be no change in the usage of the output since pkg-config
currently groups all flag types together.
For some flags, pkg-config will sort them by the depth of their .pc path
before outputting. The idea is that flags from a deeper path should come
earlier in the command line. This makes sense for -L and -I flags, but
not for generic linker and compiler flags. For these flags and -l flags,
it makes sense to sort them only by package order.
Prior to commit 6ecf318, the resolved list of required packages was
built in an appending way where each package on the command line or in
Requires would appear in the list in the order they appeared. With
6ecf318, that list building was changed to prepending, which had a
subtle change on the resolved order.
For example, suppose package a has "Requires: b c d". Previously, the
list would be built as a->b->c->d by appending each as they were
encountered. Now, the list is built by walking all the way down the
dependency chain for each package in a depth first manner and prepending
packages while unwinding. This would result in the package ilst being
a->d->c->b. This same effect happens with the command line packages
where previously requesting packages x and y would create a package list
of x->y and now produces a list of y->x.
While technically these should be the same since there are no
interdependencies, it's causes flags to be output in different order
than previously in pkg-config. This can be seen most readily in the
check-gtk test.
Instead, operate on the package lists backwards when building the
resolved package list.
Makes the resolved package list be correctly serialized with each
package only appearing once. This provides more consistency between the
various flag outputs by ensuring that the flags from each package are
only grabbed once. This makes a difference since the duplicate flag
stripping happens from the end of the output (-l) or the beginning of
the output (-L/-I/other).
Often the expected results for the indirect dependency tests fell behind
because it's not a typical test scenario. However, since the results are
always the same as --static, they can just use the same results and the
test can be run conditionally without --static based on configuration.
The pkg-config testsuite has pretty good coverage of the implementation,
but it lacks a complex case that tests the interactions of non-trivial
.pc files. gtk is a very common package that meets this goal. This is a
snapshot from my F16 system, and it should provide a good way to see how
changes in the implementation regress a real world case.
pkg-config aggressively strips all duplicate arguments from the final
output it builds. This is not only and optimization, but it also allows
the flag ordering to work correctly when a package on the command line
is required by another on the command line.
The current tests are good at checking whether gathering the Cflags or
Libs from one or two packages works correctly, but they don't check the
sorting algorithm much at all. In particular, the interactions between
the package order in the Requires chain and in the path can make the
sorting of the flags subtly different.
