GLib out of the box does not support being built for multiple arches.
This means pkg-config using the internal glib can't be built as a
universal binary on OS X. Document this and available workarounds.
Freedesktop #52032
Prior to pkg-config 0.24, --exists honored Requires and
Requires.private. This was regressed in commits 02d5ae3f and 669bfe2e,
which split the handling of Requires and Requires.private out more
correctly for other options. This adds exists to the group of options
that enable the Requires functionality.
Freedesktop #43149
Currently the check-missing passes the packages on the command line with
no options prior to running through --cflags/--libs, etc. Make this more
explicitly pass --exists since this is a much more common operation
performed from PKG_CHECK_MODULES.
The expected result of 0 when Requires or Requires.private is missing is
a regression from pre-0.24 pkg-config.
Until the needed surgery is done to remove gettext support from the
internal glib (since pkg-config doesn't need it), make sure that libintl
is linked in when necessary.
If only PKG_CONFIG_PATH is set when running the tests, we'll still pick
up packages from the system default path. By overriding that with
PKG_CONFIG_LIBDIR and unsetting PKG_CONFIG_PATH, the path is forced to
the check directory.
Replace deprecated macros and use the new libtool syntax. The required
versions of the tools have been bumped up to match the versions of the
bundled glib. This was effectively the requirement, anyway. The new
required autotools versions are:
autoconf-2.62 (released 2008-04-08)
automake-1.11 (released 2009-05-17)
libtool-2.2 (released 2008-03-01)
Also use silent rules to quiet the build a bit.
Freedesktop #34382
acconfig.h was being used to undefine some macros, but these aren't
actually used anywhere in the pkg-config code. I suspect this was a
holdover from when glib-1 was used internally. glib does define some
similar macros, but that code is all self-contained there and not
anything we need to worry about in pkg-config.
g_win32_get_package_installation_subdirectory() has been deprecated
since GLib 2.18 and in recent (2.31) GLib versions disabled entirely by
default. This patch replaces usage of that function by
g_win32_get_package_installation_directory_of_module() and
g_build_filename(). Use the new functions and rework the code a bit so
it leaks less memory.
g_win32_get_package_installation_directory_of_module() is supported
since GLib 2.16. The minimal GLib version is bumped accordingly.
Freedesktop #45742
A few of the options in configure.ac were poorly quoted or didn't have
messages matching the typical autoconf style. PKG_CONFIG_FIND_PC_PATH
also had no reason to exist since it was used once immediately after its
definition.
With the conversion to GOption and g_shell_parse_argv, pkg-config has no
remaining usage of popt. Stop linking to libpopt and removed the bundled
sources.
Fixes Freedesktop #5326, #31700, #44843
Use glib's GOption instead of popt for command line option
handling. The APIs and output are very similar. A couple minor
differences are:
* The callback for handling --define-variable is associated only with
that option where popt was just leaving the argument and then it was
handled in a generic callback.
* Remaining arguments after option parsing are in argc/argv while they
are collected through poptGetArg with popt.
* GOption does not provide the short --usage summary.
This also works around bugs in the command line option handling with
the ancient internal popt.
Glib's g_shell_parse_argv offers basically a 1:1 replacement for
poptParseArgvString except that you have to free all the elements of
the array explicitly.
From the LFS mailing list looking into why check-cmd-options fails using
the bundled popt:
poptGetNextOption, after it invokes the callback for
--define-variable=a=b (the operation of which sets the longArg local
variable), does not reset longArg to NULL. So on the next time through
its loop (after invoking the --define-variable callback, before invoking
the --atleast-pkgconfig-version callback), on line 389 of popt.c, sets
con->os->nextArg to longArg (the old "a=b" string). What it should do
is set nextArg to nextCharArg (the next item on the command line). This
happens if longArg is NULL.
http://linuxfromscratch.org/pipermail/lfs-dev/2011-September/065065.html
Freedesktop #9584
Since there's no DIST_CONFIGURE_FLAGS, the best we can do to not require
glib's configure to always be run is to error on dist when we haven't
configured --with-internal-glib. This is a hack, but I think it's
slightly nicer than overriding dist and re-running configure with
different options than were specified by the user.
The glib configure script takes a long time to run, so we want to avoid
it in the default case where we're using the system's glib.
Unfortunately, that means we can't add it unconditionally to
DIST_SUBDIRS since distclean will not always find Makefiles when it
descends into glib.
Make glib only be part of DIST_SUBDIRS when we've configured it. This
will require a different hack to make sure dist always includes glib.
This reverts commit 1860fc8036.
distclean breaks if glib is in DIST_SUBDIRS but we haven't actually
generated the glib Makefiles by running glib's configure.
The code for --exact/atleast/max-version was taking a different path
than the handling of operators like =/>=/<=. Make the long option
versions override the operators and take place during the standard
package checking stage. This also means that --print-errors is
respected.
Fixes Freedesktop #8653
Some distros and users have unusual installation needs that don't
conform to the standard $libdir/pkgconfig and $datadir/pkgconfig
pathways. Help packagers support these users with the macros
PKG_INSTALLDIR and PKG_NOARCH_INSTALLDIR. These are simple macros that
provide the configure parameters --with-pkgconfigdir and
--with-noarch-pkgconfigdir to allow users to override the standard
locations.
Freedesktop #48743
We want to distribute the glib subdir, but we want to avoid configuring
it for the default build case where the system glib is used. Override
the standard dist target so that we can reconfigure with
--with-internal-glib if necessary. I think the target should be
compatible with the original dist.
This is pretty hacky and may need to be reverted if it breaks dist.
It's nice to say that glib is a base library and you should have it
installed to build pkg-config, but it makes bootstrapping pkg-config
really annoying since it introduces a circular dependency.
Let's be nice to our users and bundle a copy to avoid this situation.
The default is still to use the system's glib, but the internal copy
can be used by passing --with-internal-glib to configure. The latest
stable copy of glib is included and will be updated periodically with
their stable releases.
The top level autogen.sh is running recursively through glib. If this
becomes an issue, we can switch autoreconf to --no-recursive and then
descend to glib and run its autogen.sh script.
Since this is default off, its integration will probably not be tested
often. Therefore, it's forcefully turned on during distcheck to make
sure to test it out before distributing a tarball.
We just want to be able to build glib from the within the pkg-config
tree. Everything else is just extra weight and is better used from an
actual glib checkout. Unnecessary files include:
* documentation
* translations
* tests
* ChangeLogs
* non-autotools win32 build files
* various other build and/or internal files
Add a snapshot of the current stable version of glib, glib-2.32.0. Since
we only need the glib library, a lot of files are removed. See the
README and update-glib.sh files in glib-patches for details.
