While gcc on Windows allows being passed -rpath and just ignores it,
llvm/lld will fail with "lld: error: unknown argument: -rpath".

There is no such thing as rpath on Windows, so just skip it.

The existing code tries to mirror how the linker finds DLLs by
searching for the import libs and then looking for the matching
shared lib name.

While llvm has a dlltool clone it doesn't provide the --identify
option to extract the shared lib name. Instead we use the fact that
llvm import libs include the dll name in the archive member name, so
we can use "nm" there to get the same result.

To decide which strategy to use we run dlltool and check if it contains
"llvm-dlltool" in the output.

This fixes the .gir and .typelib files containing bogus values for the
shared library names when building with clang + mingw-w64 on Windows.

I'm not quite sure if the libtool part is actually needed there,
but I left it in to keep the diff small.

cmph is vendored and other one is bison/flex generated code.
Not much we can do here, so disable those warnings there.

The toolchain is different enough to warrant its own CI job imo.

This parameter may not be NULL even if the function described by the
GIFunctionInfo has a void return type, so we should not say this in the
documentation.

The test returns a newly allocated GValue, so it should not be marked
transfer none.

https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html

Based on https://github.com/katef/kgt/blob/c9d8ad246855c6b65e42371be7898f4073c28d18/examples/c99-grammar.iso-ebnf#L247-L252

This helps with gtk!4965.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

GLib has been requiring a C99 toolchain for a while, now. It makes no
sense to have gobject-introspection depend on C89.

GLib commit: 2.73.3-44-g66c4e35e2

When g-ir-scanner is used by another project, than that project might
have the GLIB_VERSION_* macros defined. This is useful to ensure that
only intended glib API is used.

The project might then also pass the CFLAGS to g-ir-scanner, without
filtering those defines out. This can lead to compiler warnings.

For example, NetworkManager sets the version macros to GLIB_VERSION_2_40
and thus gets these warnings

  /NetworkManager/tmp-introspect66917zc4/NM-1.0.c: In function ‘dump_object_type’:
  /NetworkManager/tmp-introspect66917zc4/NM-1.0.c:252:13: warning: Not available before 2.70
    252 |   if (G_TYPE_IS_FINAL (type))
        |             ^~~~~~~~~~~~~~~~~
  /NetworkManager/tmp-introspect66917zc4/NM-1.0.c: In function ‘dump_fundamental_type’:
  /NetworkManager/tmp-introspect66917zc4/NM-1.0.c:370:13: warning: Not available before 2.70
    370 |   if (G_TYPE_IS_FINAL (type))
        |             ^~~~~~~~~~~~~~~~~

But these warnings are not correct. The installed g-ir-scanner knows for which
glib version to generate code. Undefine the macros to avoid the warning.

GLib commit: 2.74.0