For the same reasons as in commit 71061fdcb3, but in this
case we can’t downgrade the version of Meson on the CI runner (see the
previous commit), so just tell it to shut up instead.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3262
Rather than pinning it to the lowest version we support, as is the
standard policy.
This means we’ll end up using version 1.3.2-2, which has just been
packaged to contain the fix for
https://github.com/mesonbuild/meson/issues/12330, which has been
impacting GLib significantly since we started installing
gobject-introspection in CI in commit
c428d6e673.
Thanks to Christoph Reiter, Luca Bacci and Simon McVittie for diagnosing
and fixing this issue.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3262
This is a behaviour change from g-ir-generate, which treats it as
least-important-first (the last directory on the command-line is
searched first).
gi-compile-repository --includedir and gcc -I are most-important-first
(the first directory on the command-line is searched first) so it seems
like it makes most sense to be consistent with that.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This should make the code a bit more usable in situations where people
aren’t potentially using MSVC.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3255
`GITypeInfo` isn’t defined in `libgirepository-internals`, and that was
forcing us to do some header includes which violated the layering
between `libigrepository-internals` and `libgirepository`. Fix that by
moving the helper function to the header/source where `GITypeInfo` is
defined.
This fixes commit 54f156bd63.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
We certainly won't find the requested namespace in a newly-created
repository with no typelibs loaded.
Fixes: 9ab84bc1 "girwriter: Stop using the singleton GIRepository"
Signed-off-by: Simon McVittie <smcv@collabora.com>
The positional parameters are declared as G_OPTION_ARG_FILENAME_ARRAY,
but only the first one is used.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This seems to have been a remnant of support for embedding the typelib
in the shared library, which was removed from this tool in commit 4bf5ef6b
"[girepository] Actually verify header of loaded typelibs in
g_irepository_require" (originally gobject-introspection@05ffd857).
The feature of embedding the typelib in a shared library was itself
removed in commit b2df59c3 "compiler: Remove --code argument",
originally gobject-introspection@ac81f3e8, with a note that because
we rely on being able to load the shared library into g-ir-scanner,
anything that links g-ir-scanner output into the shared library would be
a circular dependency.
Signed-off-by: Simon McVittie <smcv@collabora.com>
It seems cleaner to store this in the parser, rather than having the
compiler export a global variable that the parser must read.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This hasn't actually done anything since commit 45a04358
"[gircompiler] Clean up parsing" (originally
gobject-introspection@8942500c).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Deriving from two templates means the `before_script` from the second
one overrides, rather than adding to, the one from the first.
Avoid that when using `.build-linux` and `.with-git` by explicitly
joining both scripts.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
On i386 Linux, the minimal ABI alignment of a double is only 4, and
therefore the alignment of GDoubleIEEE754 is also 4.
Signed-off-by: Simon McVittie <smcv@collabora.com>
It's helpful for the assertion message to say what we were expecting and
what we actually got. It's also useful to have g_test_message()
diagnostics to indicate how far into the test we were.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously we didn't test these at all, which made it hard to determine
whether %Ec, %EC had appropriate output on platforms where era-based
dates are unsupported. Now we do, and we can observe that on platforms
with no support for era-based dates, %c matches %Ec and %C matches %EC,
as desired.
Signed-off-by: Simon McVittie <smcv@collabora.com>
I can't read Japanese, but these match the output of:
env TZ=UTC LC_ALL=ja_JP.eucjp date -d2009-10-24T00:00:00Z '+%c' | iconv -f eucjp -t UTF-8
env TZ=UTC LC_ALL=ja_JP.eucjp date -d2009-10-24T00:00:00Z '+%C' | iconv -f eucjp -t UTF-8
which seem like a reasonable thing to use as a reference.
According to Google Translate, 平成 refers to the Heisei era, which was
current during 2009, and seems unreasonable to expect as output on a
platform where era-based dates are unsupported.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3252
Signed-off-by: Simon McVittie <smcv@collabora.com>
On a fast laptop, this test currently takes about 7s to run, which is a
significant portion of the overall test suite time.
On a slower CI machine, especially running the test under valgrind, the
test can time out.
There’s no need to always run so many iterations: we run the tests under
CI so often that it’s likely a failure will eventually be hit (if there
is a bug) even with fewer iterations. We also now run the tests once a
week with `-m slow`, so the original iteration count will also still be
used then.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
To avoid a big introspection API break.
These APIs are now listed in the new `{GLib,Gio}{Unix,Win32}-2.0.gir`
files, but for backwards compatibility they need to continue to be
listed in `Gio-2.0.gir` and `GLib-2.0.gir` as well, until the next major
introspection API break (and none is planned).
No new platform specific APIs should be added to these GIR files, but
these existing ones must remain.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3892#note_2001361
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
So now introspection users will have to call `GLibUnix.open_pipe()`
rather than `GLibUnix.unix_open_pipe()` — or
`GLibWin32.check_windows_version()` rather than
`GLibWin32.win32_check_windows_version()`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
