By using PKG_CHECK_VAR, we declare $GLIB_COMPILE_SCHEMAS,
$GLIB_GENMARSHAL, $GOBJECT_QUERY, $GLIB_MKENUMS and
$GLIB_COMPILE_RESOURCES as Autoconf "precious variables" with AC_ARG_VAR,
similar to $PKG_CONFIG and $CC, so that they can be put on a configure
command line:
./configure GLIB_COMPILE_RESOURCES=my-glib-compile-resources
If they are set to a non-empty value, PKG_CHECK_VAR will use that
instead of auto-detecting from pkg-config, so that builders can
override them, for example when cross-compiling.
Similarly, use the standard PKG_CHECK_MODULES macro to get GLib's CFLAGS
and LIBS.
It's possible that most of the rest of each macro can also disappear,
but for the moment I've given them the benefit of the doubt.
This does result in printing "checking for GLIB" twice (once for
PKG_CHECK_MODULES and once for GLib's custom checks), but if you're
using Autotools, you probably don't have a strong objection to overly
verbose output.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This avoids the convenience library being treated as though it was
an installed static library (objects not included in the dependent
static library, and convenience library being listed in the pkg-config
metadata), both of which would make static linking impossible.
This is a workaround for meson not having
https://github.com/mesonbuild/meson/pull/3939 merged yet.
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/1536
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we tell clang that we're passing the arguments on to a compatible
printf call, it can see that we're doing it right, and won't warn us
about -Wformat-nonliteral. This follows up from commit abac67c0.
Signed-off-by: Simon McVittie <smcv@collabora.com>
libmount depends on libblkid, so if we statically link a trivial
executable to GIO, we need to pull in both libmount and libblkid.
Linking with -lmount is not enough to achieve that, but recursing
into mount.pc is.
This makes the Autotools build a bit more like the Meson build,
which already puts mount in Requires.private.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is detected by Debian's Lintian tool, which suggests
"allows one to" as a replacement. I've rephrased the documentation
in question to avoid both of those.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The text about deallocation of GArrays with elements containing
dynamically-allocated memory was confusing. It initially mentioned
clear_func, but later said elements with dynamically allocated memory
"should be freed separately".
Clarify this by using the same structure as g_ptr_array_free —
highlight the need to set a clear_func by consolidating the text about
it in a separate paragraph.
https://gitlab.gnome.org/GNOME/glib/merge_requests/348
None of these files starts with a #! line, and they are not native
binary executables, so if a user attempts to execute them as a program,
Unix shells will run them as /bin/sh scripts. This is not going to end
well, since none of them are shell scripts (the gio bash completion
is for bash, which is not a lowest-common-denominator POSIX shell, and
in any case is designed to be sourced rather than executed).
Fixes: #1539
Signed-off-by: Simon McVittie <smcv@collabora.com>
As we recently established, G_G*_FORMAT macros are for glib
functions *only*. It's not guaranteed that they will work for
C runtime printf() or scanf() variants, and indeed - in this case
they do not (GCC thinks that MSVCRT sscanf() requires %I64 prefix
for 64-bit values; whether that is true or not is irrelevant at this
point - we need to make the werror go away).
LPARAM is LONG_PTR which is the same as INT_PTR on Windows.
WPARAM is UINT_PTR.
HWND is a pointer.
(%p prints pointers without 0x prefix, hence the extra 0x).
