GitLab

Make the variable names intelligible, and include a bunch of built files
that are necessary to ensure that the generated GIR data actually
matches the GLib API.

Because of skepticism I received in #224, I made this PR which keeps the
testsuite and CI improvements but doesn't add any new build options. I
hope this would be less controversial:

 - no new knobs
 - tests for those using existing build options
 - CI tests `build_introspection_data = false`

meson inserts the dependency if the compiler is used directly, but
fails to do so if the compiler is run through a wrapper. This leads
to build race errors between building the compiler and using it.

Fix provided by Quentin Schulz <quentin.schulz@streamunlimited.com>

The old name used "host" according to Yocto's definition, but not
Meson's. The new name works for everyone.

Actually, we shouldn't really need this. We are building `native: false`
binaries so when we look up a `native: true` binary the override should
not apply. I've fixed this upstream in meson in
https://github.com/NixOS/nixpkgs/pull/86080, though some backwards
compatibility migration might be in order.

In the meantime, we can make `gi_cross_use_host_gi` prevent the
overrides from happening, which will achieve the desired behavior.

Finally, this allows us to use `find_program` in `scanner_command`,
unconditionally, letting the presence of the override dictate whether a
freshly-built or pre-built `g-ir-scanner` is used.

Newer meson warns that option names can't start with "cross_", so
we have to prefix them:

"Option uses prefix "cross_", which is reserved for Meson. This will become an error in the future."

This avoids compilation erroring out on C4819 (Unicode handling issue in the
Visual Studio compiler), notably when running on Chinese, Japanese and Korean
(CJK) locales.

This also applies -utf-8 into the cflags passed into the various g-ir-scanner
command lines that are used to generate the *.gir files, where -utf-8 is
available, so that we don't get flooded with C4819 warnings during the
build, and therefore avoid potential mishaps, as C4819 is a real warning that
warngs us the code may be incorrectly built.

See here:
!64



Particularly, options are renamed to make it more readable and clear.
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>

meson_options.txt: add host-gi, gi-cross-wrapper, gi-ldd-wrapper, introspection-data and pkgconfig-sysroot-path options

With the first option, gobject-introspection tools (g-ir-doc-tool and g-ir-scanner)
that are already installed in the host system will be used for building the source tree.

With the second option, g-ir-scanner will be instructed to use an executable
wrapper to run binaries it's producing, and g-ir-compiler will be run
through the same wrapper (host system's g-ir-compiler cannot be used because
it's producing architecture-specific output).

With the third option, giscanner will be instructed to use a special ldd
command instead of system's ldd (which does not work when the binary to inspect
is compiled for a different architecture).

With the fourth option, it is possible to disable building of introspection data
(.gir and .typelib files), which may be difficult or impossible in cross-compilation
environments, because of lack of emulation (or native hardware) for the target architecture
on which the target binaries can be run.

With the fifth option, paths returned by pkg-config are prefixed with the sysroot
path (which is the destination path for cross-compiled items on the system where
cross-compilation happens).

These options are useful when cross-compiling for a different target architecture.
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>

Closes: #300.

The cairo MSVC build produces a cairo-gobject.dll unlike the
libcairo-gobject-2.dll with autotools.

While one can pass the right DLL name through the cairo_libname option,
having a better default can't hurt.

host_machine.system() returns "windows" on Windows

Less noisy build

The newly added GTypes in glib!481 result in g-i generating an enum type
in GLib-2.0 and a GType based one in GObject-2.0.

This makes problems for the dlang bindings (see #267) so skip them for now.

Ideally we should include it in GLib-2.0 like we do with glib-types.h.

This is what https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting suggests.

This adds the following macros and functions: GI_MAJOR_VERSION, GI_MICRO_VERSION,
GI_MINOR_VERSION, GI_CHECK_VERSION, gi_get_major_version,gi_get_micro_version,
gi_get_minor_version.

Since we share a prefix with glib we have to namespace these by using the gi_
prefix. g_gi would also work but we already export symbols with gi_ like
gi_cclosure_marshal_generic(), gi_type_tag_get_ffi_type() and
gi_type_info_extract_ffi_return_value(), so let's not add another naming scheme.

This should address flaky builds on vs2017-x64-meson.

API from gobject/gvaluecollector.h is not intended for introspected use.
Skip it when scanning headers. This effectively hides the definition of
GTypeCValue and VALUE_COLLECT_FORMAT_MAX_LENGTH constant.

Add option 'gir-dir-prefix' for meson to make the installation path of
.gir files could be configured which has been done for autoconf.
Signed-off-by: Kai Kang <kai.kang@windriver.com>

This allows us to build with Python 2 and run tests with it.
This requires the new "python" meson module which was added in 0.46.0 so
bump the required meson version (glib needs a newer one anyway).

Also fixes a small test error under Python 2.

Always use gobject-introspection-1.0 we have just built,
when running g-ir-scanner for girepository.

To make it build using libintl as a subproject on Linux.

Håvard Graff authored Dec 04, 2017 and Nirbheek Chauhan committed Mar 10, 2018

To make it build using libffi as a subproject on Linux.

This ensures stability in the output, because the underlying
implementation uses readdir() and the output will depend on the
filesystem.

This also works around a bug where g-ir-scanner's source scanner was
 #include-ing gmarshal.h before any other header which resulted in all
marshaling symbols to be skipped from the introspection because of
syntax errors.

Otherwise we will see the fallback annotations provided in glib-2.0.c
etc and use them instead of the up-to-date annotations in glib's
source code.

This is a hack for use by people who use a different subproject
directory than the default.

When building from scratch on Windows using subprojects, we have neither
pkg-config nor any system libraries so we need to link to gio/glib/etc
manually.

Danny 'Guru' Forghieri authored Nov 01, 2017 and Nirbheek Chauhan committed Mar 10, 2018

Signed-off-by: Nirbheek Chauhan <nirbheek@centricular.com>

Danny 'Guru' Forghieri authored Oct 29, 2017 and Nirbheek Chauhan committed Mar 10, 2018

Both the source and the build dir are needed because some files are
read from the source and others are read after they are built.
Signed-off-by: Nirbheek Chauhan <nirbheek@centricular.com>

Otherwise it won't run on Windows because it doesn't have a .py suffix
and it isn't an executable. Meson should probably detect this case and
automatically insert python3.

When building with Meson, we cannot set environment variables while
running custom targets and our builddir layout is different from
Autotools anyway.

Now g-ir-scanner and friends can autodetect when they're being run
uninstalled by Meson and will find _giscanner.so and the giscanner
python files in the build directory. This is very similar to what
gdbus-codegen uses in glib/gio.

Same for girepository/gdump.c.

The previous build files had a bunch of problems:

1. It assumed that glib would only be sourced via pkg-config
2. It was using the system gobject-introspection-1.0.pc file while
   building GIRepository-1.0.gir
3. It wasn't ignoring the *-autocleanup.h headers properly

Now you can build glib as a subproject and generate girs against the
in-tree sources. This also yields more accurate girs because they
document platform-specific features that are actually enabled in
the glib build we are linking against.