luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2024-12-29 08:56:15 +01:00
Code Issues Packages Projects Releases Wiki Activity
6faed43505
glib/girepository/introspection/meson.build

380 lines
11 KiB
Meson
Raw Normal View History

build: Factorize some common values in gi generation
2023-12-20 21:20:04 +01:00
gi_identifier_prefix = 'G'
gi_symbol_prefix = 'g'
gi_gen_shared_sources = [
# Required to compile gdump
gmodule_visibility_h,
]
introspection: Add libgirepository as a dep to all generate_gir() calls libgirepository is not needed by most of the modules, but it is needed by the `g-ir-scanner` generated dumper program. If we don’t explicitly include the local version of it here, Meson will implicitly link against it anyway, and that might pull in a different version, or try to link against a half-built local version as the build ordering dependency tree won’t reflect this relationship. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Fixes: #3401
2024-06-26 13:48:32 +02:00
gi_gen_shared_dependencies = [
# libgirepository is not needed by most of the modules below, but it is needed
# by the g-ir-scanner generated dumper program. If we don’t explicitly include
# the local version of it here, Meson will implicitly link against it anyway,
# and that might pull in a different version, or try to link against a
# half-built local version as the build ordering dependency tree won’t
# reflect this relationship.
libgirepository_dep,
]
build: Ignore ASAN link order errors when generating typelib files Without this when compiling GLib with address sanitizer enabled, we'd end up failing with this error: ==375535==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. Now, given that addressing the fix implies doing more radical changes, it's just fine here to ignore ASAN to work on tools we use for building gir files.
2023-12-20 21:35:40 +01:00
gi_gen_env_variables = environment()
girepository/introspection: Set asan option only on address sanitizer It's the only sanitizer failing when generating the introspection data
2024-05-10 02:42:42 +02:00
if 'address' in glib_sanitizers
build: Ignore ASAN link order errors when generating typelib files Without this when compiling GLib with address sanitizer enabled, we'd end up failing with this error: ==375535==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. Now, given that addressing the fix implies doing more radical changes, it's just fine here to ignore ASAN to work on tools we use for building gir files.
2023-12-20 21:35:40 +01:00
gi_gen_env_variables.append(
'ASAN_OPTIONS', 'verify_asan_link_order=0', separator: ',')
endif
Introspection: Fix running g-ir-scanner 1.80.x+ on Windows Since we are now building introspection files for GLib while building GLib, so we want to make sure that we indeed load the freshly-built DLLs when running g-ir-scanner, so we add the various needed subdirs (and if needed, subprojects), to set the GI_EXTRA_BASE_DLL_DIRS envvar so that g-ir-scanner will look for the newly-built GLib DLLs. Ideally, upstream g-ir-scanner will need to be updated accordingly to do something similar to what we are doing here, but this is needed until the time that we require a g-ir-scanner that contains the update. This will also fix the g-ir-scanner erroring out when there is no pre-existing GLib on the system, as the needed DLLs are now found. Related issue: https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/499 Related MR in G-I: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/458
2024-03-28 11:36:41 +01:00
if host_system == 'windows'
# Use gio-2.0-uninstalled.pc to find the paths where the GLib DLLs (and their dependent non-system
# DLLs that are built as subprojects) are located
check_built_dll_paths_cmd = [get_dll_paths_script, '--build-path=@0@'.format(meson.project_build_root())]
meson_pkgconfig_paths = get_option('pkg_config_path')
if meson_pkgconfig_paths.length() > 0
check_built_dll_paths_cmd += '--pkg-config-path=@0@'.format(''.join(meson_pkgconfig_paths))
endif
check_built_dll_paths = run_command(
check_built_dll_paths_cmd,
capture: true,
check: true,
)
# hmm, no os.pathsep in Meson to make this more portable, if needed?
gi_scanner_dll_paths = check_built_dll_paths.stdout().strip().split(';')
# Also assume the existing paths in %PATH% to be considered for DLLs
message('Ensure that all of GLib\'s dependent non-system DLLs that are not built')
message('alongside with GLib can be found in paths in %PATH%')
message('Check this if building .gir files fail due to \'ImportError: DLL load failed while importing _giscanner\'')
gi_gen_env_variables.set('GI_EXTRA_BASE_DLL_DIRS', gi_scanner_dll_paths)
endif
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
# GLib
introspection: Re-add platform specific APIs to GLib-2.0.gir and Gio-2.0.gir 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>
2024-02-12 16:17:20 +01:00
glib_gir_sources = [
gi_gen_shared_sources,
glibconfig_h,
gversionmacros_h,
glib_visibility_h,
glib_headers,
glib_deprecated_headers,
glib_sub_headers,
glib_enumtypes_h,
glib_types_h,
glib_deprecated_sources,
glib_sources,
build: Add docs.c to the GLib GIR For historical reasons, some doc blocks are included in an ancillary file. Add it to the list of sources parsed by g-ir-scanner, to increase the coverage of various macros. Fixes: #3372
2024-05-20 14:34:19 +02:00
files('../../glib/docs.c'),
introspection: Re-add platform specific APIs to GLib-2.0.gir and Gio-2.0.gir 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>
2024-02-12 16:17:20 +01:00
]
# For API compatibility reasons, GLib-2.0.gir needs to contain the platform
# specific APIs which are also present in the (newer) GLibUnix-2.0.gir and
# GLibWin32-2.0.gir repositories.
# See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3892#note_2001361
# These can be dropped when GLib next breaks API (i.e. with GLib-3.0.gir).
if host_system == 'windows'
glib_gir_sources += files('../../glib/gwin32.h')
else
glib_gir_sources += files('../../glib/glib-unix.h')
endif
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
glib_gir = gnome.generate_gir(libglib,
introspection: Re-add platform specific APIs to GLib-2.0.gir and Gio-2.0.gir 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>
2024-02-12 16:17:20 +01:00
sources: glib_gir_sources,
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
namespace: 'GLib',
nsversion: '2.0',
build: Factorize some common values in gi generation
2023-12-20 21:20:04 +01:00
identifier_prefix: gi_identifier_prefix,
symbol_prefix: gi_symbol_prefix,
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
export_packages: 'glib-2.0',
header: 'glib.h',
install: true,
girepository/introspection: correctly install .gir files into custom locations There is a meson option (gir_dir_prefix), but without being passed in here the files would always get installed into the default location (datadir). Signed-off-by: Alexander Kanavin <alex@linutronix.de>
2024-04-23 11:24:34 +02:00
install_dir_gir: glib_girdir,
introspection: Add libgirepository as a dep to all generate_gir() calls libgirepository is not needed by most of the modules, but it is needed by the `g-ir-scanner` generated dumper program. If we don’t explicitly include the local version of it here, Meson will implicitly link against it anyway, and that might pull in a different version, or try to link against a half-built local version as the build ordering dependency tree won’t reflect this relationship. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Fixes: #3401
2024-06-26 13:48:32 +02:00
dependencies: gi_gen_shared_dependencies + [
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
libgobject_dep,
],
build: Ignore ASAN link order errors when generating typelib files Without this when compiling GLib with address sanitizer enabled, we'd end up failing with this error: ==375535==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. Now, given that addressing the fix implies doing more radical changes, it's just fine here to ignore ASAN to work on tools we use for building gir files.
2023-12-20 21:35:40 +01:00
env: gi_gen_env_variables,
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
extra_args: gir_args + [
'-DGLIB_COMPILATION',
'-DGETTEXT_PACKAGE="dummy"',
'--symbol-prefix=glib',
'--library-path=' + meson.current_build_dir(),
'--library=gobject-2.0',
],
)
introspection: Generate separate GIR files for platform specific APIs For both GLib and GIO. (GObject, GIRepository and GModule don’t have any platform specific APIs.) This is needed for two reasons: * If the same GIR file is shipped on multiple platforms, it has no way to conditionally define/not-define an API based on the platform (like an `#ifdef` in a C header). So we either end up shipping differing GIR APIs on different platforms, or shipping a GIR file which declares APIs which aren’t resolvable by `dlopen()` on certain platforms, and will cause a language runtime error. * The API reference documentation is now generated from the GIR, and similar problems are present there: if the GIR contains different symbols depending on the platform, there is no way to generate API documentation for the union of all of them. The fix is to ensure that there are no conditional symbols in a GIR, by splitting out the platform specific symbols into platform specific GIR files. Platform specific documentation can then be generated from these, in addition to the main, platform agnostic, documentation. The documentation changes will following in a subsequent commit. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2024-02-06 16:29:30 +01:00
if host_system == 'windows'
glib_win32_gir = gnome.generate_gir(libglib,
sources: [
gi_gen_shared_sources,
glib_win32_headers,
],
namespace: 'GLibWin32',
nsversion: '2.0',
identifier_prefix: gi_identifier_prefix,
symbol_prefix: gi_symbol_prefix,
export_packages: 'glib-2.0',
header: 'glib.h',
includes: [ glib_gir[0] ],
install: true,
girepository/introspection: correctly install .gir files into custom locations There is a meson option (gir_dir_prefix), but without being passed in here the files would always get installed into the default location (datadir). Signed-off-by: Alexander Kanavin <alex@linutronix.de>
2024-04-23 11:24:34 +02:00
install_dir_gir: glib_girdir,
introspection: Add libgirepository as a dep to all generate_gir() calls libgirepository is not needed by most of the modules, but it is needed by the `g-ir-scanner` generated dumper program. If we don’t explicitly include the local version of it here, Meson will implicitly link against it anyway, and that might pull in a different version, or try to link against a half-built local version as the build ordering dependency tree won’t reflect this relationship. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Fixes: #3401
2024-06-26 13:48:32 +02:00
dependencies: gi_gen_shared_dependencies + [
introspection: Generate separate GIR files for platform specific APIs For both GLib and GIO. (GObject, GIRepository and GModule don’t have any platform specific APIs.) This is needed for two reasons: * If the same GIR file is shipped on multiple platforms, it has no way to conditionally define/not-define an API based on the platform (like an `#ifdef` in a C header). So we either end up shipping differing GIR APIs on different platforms, or shipping a GIR file which declares APIs which aren’t resolvable by `dlopen()` on certain platforms, and will cause a language runtime error. * The API reference documentation is now generated from the GIR, and similar problems are present there: if the GIR contains different symbols depending on the platform, there is no way to generate API documentation for the union of all of them. The fix is to ensure that there are no conditional symbols in a GIR, by splitting out the platform specific symbols into platform specific GIR files. Platform specific documentation can then be generated from these, in addition to the main, platform agnostic, documentation. The documentation changes will following in a subsequent commit. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2024-02-06 16:29:30 +01:00
libgobject_dep,
],
env: gi_gen_env_variables,
extra_args: gir_args + [
'-DGLIB_COMPILATION',
'-DGETTEXT_PACKAGE="dummy"',
'--symbol-prefix=glib',
introspection: Drop Unix and Win32 prefixes from platform specific APIs 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
2024-02-09 00:58:26 +01:00
'--symbol-prefix=g_win32',
'--identifier-prefix=GWin32',
introspection: Generate separate GIR files for platform specific APIs For both GLib and GIO. (GObject, GIRepository and GModule don’t have any platform specific APIs.) This is needed for two reasons: * If the same GIR file is shipped on multiple platforms, it has no way to conditionally define/not-define an API based on the platform (like an `#ifdef` in a C header). So we either end up shipping differing GIR APIs on different platforms, or shipping a GIR file which declares APIs which aren’t resolvable by `dlopen()` on certain platforms, and will cause a language runtime error. * The API reference documentation is now generated from the GIR, and similar problems are present there: if the GIR contains different symbols depending on the platform, there is no way to generate API documentation for the union of all of them. The fix is to ensure that there are no conditional symbols in a GIR, by splitting out the platform specific symbols into platform specific GIR files. Platform specific documentation can then be generated from these, in addition to the main, platform agnostic, documentation. The documentation changes will following in a subsequent commit. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2024-02-06 16:29:30 +01:00
'--library-path=' + meson.current_build_dir(),
'--library=gobject-2.0',
],
)
else
glib_unix_gir = gnome.generate_gir(libglib,
sources: [
gi_gen_shared_sources,
glib_unix_headers,
],
namespace: 'GLibUnix',
nsversion: '2.0',
identifier_prefix: gi_identifier_prefix,
symbol_prefix: gi_symbol_prefix,
export_packages: 'glib-2.0',
header: 'glib.h',
includes: [ glib_gir[0] ],
install: true,
girepository/introspection: correctly install .gir files into custom locations There is a meson option (gir_dir_prefix), but without being passed in here the files would always get installed into the default location (datadir). Signed-off-by: Alexander Kanavin <alex@linutronix.de>
2024-04-23 11:24:34 +02:00
install_dir_gir: glib_girdir,
introspection: Add libgirepository as a dep to all generate_gir() calls libgirepository is not needed by most of the modules, but it is needed by the `g-ir-scanner` generated dumper program. If we don’t explicitly include the local version of it here, Meson will implicitly link against it anyway, and that might pull in a different version, or try to link against a half-built local version as the build ordering dependency tree won’t reflect this relationship. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Fixes: #3401
2024-06-26 13:48:32 +02:00
dependencies: gi_gen_shared_dependencies + [
introspection: Generate separate GIR files for platform specific APIs For both GLib and GIO. (GObject, GIRepository and GModule don’t have any platform specific APIs.) This is needed for two reasons: * If the same GIR file is shipped on multiple platforms, it has no way to conditionally define/not-define an API based on the platform (like an `#ifdef` in a C header). So we either end up shipping differing GIR APIs on different platforms, or shipping a GIR file which declares APIs which aren’t resolvable by `dlopen()` on certain platforms, and will cause a language runtime error. * The API reference documentation is now generated from the GIR, and similar problems are present there: if the GIR contains different symbols depending on the platform, there is no way to generate API documentation for the union of all of them. The fix is to ensure that there are no conditional symbols in a GIR, by splitting out the platform specific symbols into platform specific GIR files. Platform specific documentation can then be generated from these, in addition to the main, platform agnostic, documentation. The documentation changes will following in a subsequent commit. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2024-02-06 16:29:30 +01:00
libgobject_dep,
],
env: gi_gen_env_variables,
extra_args: gir_args + [
'-DGLIB_COMPILATION',
'-DGETTEXT_PACKAGE="dummy"',
'--symbol-prefix=glib',
introspection: Drop Unix and Win32 prefixes from platform specific APIs 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
2024-02-09 00:58:26 +01:00
'--symbol-prefix=g_unix',
'--identifier-prefix=GUnix',
introspection: Generate separate GIR files for platform specific APIs For both GLib and GIO. (GObject, GIRepository and GModule don’t have any platform specific APIs.) This is needed for two reasons: * If the same GIR file is shipped on multiple platforms, it has no way to conditionally define/not-define an API based on the platform (like an `#ifdef` in a C header). So we either end up shipping differing GIR APIs on different platforms, or shipping a GIR file which declares APIs which aren’t resolvable by `dlopen()` on certain platforms, and will cause a language runtime error. * The API reference documentation is now generated from the GIR, and similar problems are present there: if the GIR contains different symbols depending on the platform, there is no way to generate API documentation for the union of all of them. The fix is to ensure that there are no conditional symbols in a GIR, by splitting out the platform specific symbols into platform specific GIR files. Platform specific documentation can then be generated from these, in addition to the main, platform agnostic, documentation. The documentation changes will following in a subsequent commit. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2024-02-06 16:29:30 +01:00
'--library-path=' + meson.current_build_dir(),
'--library=gobject-2.0',
'--c-include=glib-unix.h',
],
)
endif
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
# GObject
gobject_gir = gnome.generate_gir(libgobject,
sources: [
build: Factorize some common values in gi generation
2023-12-20 21:20:04 +01:00
gi_gen_shared_sources,
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
gobject_visibility_h,
gobject_install_headers,
gobject_sources,
],
namespace: 'GObject',
nsversion: '2.0',
build: Factorize some common values in gi generation
2023-12-20 21:20:04 +01:00
identifier_prefix: gi_identifier_prefix,
symbol_prefix: gi_symbol_prefix,
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
export_packages: 'gobject-2.0',
header: 'glib-object.h',
includes: [ glib_gir[0] ],
install: true,
girepository/introspection: correctly install .gir files into custom locations There is a meson option (gir_dir_prefix), but without being passed in here the files would always get installed into the default location (datadir). Signed-off-by: Alexander Kanavin <alex@linutronix.de>
2024-04-23 11:24:34 +02:00
install_dir_gir: glib_girdir,
introspection: Add libgirepository as a dep to all generate_gir() calls libgirepository is not needed by most of the modules, but it is needed by the `g-ir-scanner` generated dumper program. If we don’t explicitly include the local version of it here, Meson will implicitly link against it anyway, and that might pull in a different version, or try to link against a half-built local version as the build ordering dependency tree won’t reflect this relationship. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Fixes: #3401
2024-06-26 13:48:32 +02:00
dependencies: gi_gen_shared_dependencies,
build: Ignore ASAN link order errors when generating typelib files Without this when compiling GLib with address sanitizer enabled, we'd end up failing with this error: ==375535==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. Now, given that addressing the fix implies doing more radical changes, it's just fine here to ignore ASAN to work on tools we use for building gir files.
2023-12-20 21:35:40 +01:00
env: gi_gen_env_variables,
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
extra_args: gir_args + [
'-DGOBJECT_COMPILATION',
'--symbol-prefix=gobject',
],
)
# GModule
gmodule_gir = gnome.generate_gir(libgmodule,
sources: [
build: Factorize some common values in gi generation
2023-12-20 21:20:04 +01:00
gi_gen_shared_sources,
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
gmoduleconf_h,
gmodule_h,
gmodule_c,
gmodule_deprecated_c,
gmodule_visibility_h,
],
namespace: 'GModule',
nsversion: '2.0',
build: Factorize some common values in gi generation
2023-12-20 21:20:04 +01:00
identifier_prefix: gi_identifier_prefix,
symbol_prefix: gi_symbol_prefix,
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
export_packages: 'gmodule-2.0',
header: 'gmodule.h',
includes: [ glib_gir[0] ],
install: true,
girepository/introspection: correctly install .gir files into custom locations There is a meson option (gir_dir_prefix), but without being passed in here the files would always get installed into the default location (datadir). Signed-off-by: Alexander Kanavin <alex@linutronix.de>
2024-04-23 11:24:34 +02:00
install_dir_gir: glib_girdir,
introspection: Add libgirepository as a dep to all generate_gir() calls libgirepository is not needed by most of the modules, but it is needed by the `g-ir-scanner` generated dumper program. If we don’t explicitly include the local version of it here, Meson will implicitly link against it anyway, and that might pull in a different version, or try to link against a half-built local version as the build ordering dependency tree won’t reflect this relationship. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Fixes: #3401
2024-06-26 13:48:32 +02:00
dependencies: gi_gen_shared_dependencies + [
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
libglib_dep,
],
build: Ignore ASAN link order errors when generating typelib files Without this when compiling GLib with address sanitizer enabled, we'd end up failing with this error: ==375535==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. Now, given that addressing the fix implies doing more radical changes, it's just fine here to ignore ASAN to work on tools we use for building gir files.
2023-12-20 21:35:40 +01:00
env: gi_gen_env_variables,
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
extra_args: gir_args + [
'-DGMODULE_COMPILATION',
'-DGETTEXT_PACKAGE="dummy"',
'--symbol-prefix=gmodule',
],
)
# Gio
gio_gir_sources = [
build: Factorize some common values in gi generation
2023-12-20 21:20:04 +01:00
gi_gen_shared_sources,
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
gio_visibility_h,
gioenumtypes_h,
gnetworking_h,
gio_headers,
gio_base_sources,
application_sources,
gdbus_sources,
contenttype_sources,
settings_sources,
]
introspection: Re-add platform specific APIs to GLib-2.0.gir and Gio-2.0.gir 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>
2024-02-12 16:17:20 +01:00
gio_gir_packages = [ 'gio-2.0' ]
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
gio_gir_args = [
'-DGIO_COMPILATION',
'-DG_SETTINGS_ENABLE_BACKEND',
'--symbol-prefix=gio',
]
introspection: Re-add platform specific APIs to GLib-2.0.gir and Gio-2.0.gir 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>
2024-02-12 16:17:20 +01:00
# For API compatibility reasons, Gio-2.0.gir needs to contain the platform
# specific APIs which are also present in the (newer) GioUnix-2.0.gir and
# GioWin32-2.0.gir repositories.
# See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3892#note_2001361
# These can be dropped when GIO next breaks API (i.e. with Gio-3.0.gir).
if host_system == 'windows'
gio_gir_sources += [ gio_win32_include_headers, win32_sources ]
foreach h: gio_win32_include_headers
build: Bump Meson dependency to 1.4.0 Meson 1.5.1 is available in the fd.o SDK and in Debian testing, so the glib Meson policy says we can update. Update the minimum only as far as 1.4.0 because we don't yet have a need for 1.5.0. This allows us to: - Use file.full_path() to avoid deprecation warnings on str.format(file). - Set c_std=gnu99,c99 to avoid deprecation warnings with gnu99 on MSVC. Update all the CI builds to use the latest 1.4.x patch release, 1.4.2. The FreeBSD runner cannot be updated via `gitlab-ci.yml`, so will be broken for now. Similarly, the macOS build will not work unless `-Dc_std=gnu99` is specified at configure time, due to https://github.com/mesonbuild/meson/issues/13639.
2024-09-05 13:31:09 +02:00
gio_gir_args += '--c-include=' + h.full_path()
introspection: Re-add platform specific APIs to GLib-2.0.gir and Gio-2.0.gir 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>
2024-02-12 16:17:20 +01:00
endforeach
introspection: Correct GIO-Windows pkg-config name It's gio-windows-2.0.pc, not gio-win32-2.0.pc. Otherwise, we get warnings/errors where the package cannot be located but since we are linking to the same GIO library file, this did not manifest itself.
2024-07-17 10:25:43 +02:00
gio_gir_packages += 'gio-windows-2.0'
gio_gir_args += '--pkg=gio-windows-2.0'
introspection: Re-add platform specific APIs to GLib-2.0.gir and Gio-2.0.gir 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>
2024-02-12 16:17:20 +01:00
else
gio_gir_sources += [ gio_unix_include_headers, unix_sources ]
foreach h: gio_unix_include_headers
build: Bump Meson dependency to 1.4.0 Meson 1.5.1 is available in the fd.o SDK and in Debian testing, so the glib Meson policy says we can update. Update the minimum only as far as 1.4.0 because we don't yet have a need for 1.5.0. This allows us to: - Use file.full_path() to avoid deprecation warnings on str.format(file). - Set c_std=gnu99,c99 to avoid deprecation warnings with gnu99 on MSVC. Update all the CI builds to use the latest 1.4.x patch release, 1.4.2. The FreeBSD runner cannot be updated via `gitlab-ci.yml`, so will be broken for now. Similarly, the macOS build will not work unless `-Dc_std=gnu99` is specified at configure time, due to https://github.com/mesonbuild/meson/issues/13639.
2024-09-05 13:31:09 +02:00
gio_gir_args += '--c-include=' + h.full_path()
introspection: Re-add platform specific APIs to GLib-2.0.gir and Gio-2.0.gir 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>
2024-02-12 16:17:20 +01:00
endforeach
gio_gir_packages += 'gio-unix-2.0'
gio_gir_args += '--pkg=gio-unix-2.0'
endif
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
gio_gir = gnome.generate_gir(libgio,
sources: gio_gir_sources,
namespace: 'Gio',
nsversion: '2.0',
build: Factorize some common values in gi generation
2023-12-20 21:20:04 +01:00
identifier_prefix: gi_identifier_prefix,
symbol_prefix: gi_symbol_prefix,
introspection: Re-add platform specific APIs to GLib-2.0.gir and Gio-2.0.gir 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>
2024-02-12 16:17:20 +01:00
export_packages: gio_gir_packages,
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
header: 'gio/gio.h',
includes: [ glib_gir[0], gmodule_gir[0], gobject_gir[0] ],
install: true,
girepository/introspection: correctly install .gir files into custom locations There is a meson option (gir_dir_prefix), but without being passed in here the files would always get installed into the default location (datadir). Signed-off-by: Alexander Kanavin <alex@linutronix.de>
2024-04-23 11:24:34 +02:00
install_dir_gir: glib_girdir,
introspection: Add libgirepository as a dep to all generate_gir() calls libgirepository is not needed by most of the modules, but it is needed by the `g-ir-scanner` generated dumper program. If we don’t explicitly include the local version of it here, Meson will implicitly link against it anyway, and that might pull in a different version, or try to link against a half-built local version as the build ordering dependency tree won’t reflect this relationship. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Fixes: #3401
2024-06-26 13:48:32 +02:00
dependencies: gi_gen_shared_dependencies + [
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
libglib_dep,
libgobject_dep,
libgmodule_dep,
],
build: Ignore ASAN link order errors when generating typelib files Without this when compiling GLib with address sanitizer enabled, we'd end up failing with this error: ==375535==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. Now, given that addressing the fix implies doing more radical changes, it's just fine here to ignore ASAN to work on tools we use for building gir files.
2023-12-20 21:35:40 +01:00
env: gi_gen_env_variables,
build: Move gir generation to an introspection folder Generating gir and typelib files has inter-dependencies that may depend on other elements. For example, glib requires gobject and gdump generated files require gmodule, so we've a cyclic dependency because gmodule requires gobject, that requires glib. To prevent this, let's just generate the introspection files at once in a different meson file so that we don't have to deal with this. As per this we could even revert commit fa37ab6d0 since gio is now compiled before the gir files.
2023-12-20 03:46:33 +01:00
extra_args: gir_args + gio_gir_args,
)
girepository: Move GIR generation into girepository and prior to tests To enable tests which depend on libgirepository's GIR and typelib, we need to refactor the order we're currently building these items. We can also move everything under girepository/ to cleanup the top-level.
2024-01-26 10:32:10 +01:00
introspection: Generate separate GIR files for platform specific APIs For both GLib and GIO. (GObject, GIRepository and GModule don’t have any platform specific APIs.) This is needed for two reasons: * If the same GIR file is shipped on multiple platforms, it has no way to conditionally define/not-define an API based on the platform (like an `#ifdef` in a C header). So we either end up shipping differing GIR APIs on different platforms, or shipping a GIR file which declares APIs which aren’t resolvable by `dlopen()` on certain platforms, and will cause a language runtime error. * The API reference documentation is now generated from the GIR, and similar problems are present there: if the GIR contains different symbols depending on the platform, there is no way to generate API documentation for the union of all of them. The fix is to ensure that there are no conditional symbols in a GIR, by splitting out the platform specific symbols into platform specific GIR files. Platform specific documentation can then be generated from these, in addition to the main, platform agnostic, documentation. The documentation changes will following in a subsequent commit. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2024-02-06 16:29:30 +01:00
if host_system == 'windows'
gio_win32_gir_c_includes = []
foreach h: gio_win32_include_headers
build: Bump Meson dependency to 1.4.0 Meson 1.5.1 is available in the fd.o SDK and in Debian testing, so the glib Meson policy says we can update. Update the minimum only as far as 1.4.0 because we don't yet have a need for 1.5.0. This allows us to: - Use file.full_path() to avoid deprecation warnings on str.format(file). - Set c_std=gnu99,c99 to avoid deprecation warnings with gnu99 on MSVC. Update all the CI builds to use the latest 1.4.x patch release, 1.4.2. The FreeBSD runner cannot be updated via `gitlab-ci.yml`, so will be broken for now. Similarly, the macOS build will not work unless `-Dc_std=gnu99` is specified at configure time, due to https://github.com/mesonbuild/meson/issues/13639.
2024-09-05 13:31:09 +02:00
gio_win32_gir_c_includes += '--c-include=' + h.full_path()
introspection: Generate separate GIR files for platform specific APIs For both GLib and GIO. (GObject, GIRepository and GModule don’t have any platform specific APIs.) This is needed for two reasons: * If the same GIR file is shipped on multiple platforms, it has no way to conditionally define/not-define an API based on the platform (like an `#ifdef` in a C header). So we either end up shipping differing GIR APIs on different platforms, or shipping a GIR file which declares APIs which aren’t resolvable by `dlopen()` on certain platforms, and will cause a language runtime error. * The API reference documentation is now generated from the GIR, and similar problems are present there: if the GIR contains different symbols depending on the platform, there is no way to generate API documentation for the union of all of them. The fix is to ensure that there are no conditional symbols in a GIR, by splitting out the platform specific symbols into platform specific GIR files. Platform specific documentation can then be generated from these, in addition to the main, platform agnostic, documentation. The documentation changes will following in a subsequent commit. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2024-02-06 16:29:30 +01:00
endforeach
gio_win32_gir = gnome.generate_gir(libgio,
sources: gio_win32_include_headers + win32_sources,
namespace: 'GioWin32',
nsversion: '2.0',
identifier_prefix: gi_identifier_prefix,
symbol_prefix: gi_symbol_prefix,
introspection: Correct GIO-Windows pkg-config name It's gio-windows-2.0.pc, not gio-win32-2.0.pc. Otherwise, we get warnings/errors where the package cannot be located but since we are linking to the same GIO library file, this did not manifest itself.
2024-07-17 10:25:43 +02:00
export_packages: [ 'gio-windows-2.0' ],
introspection: Generate separate GIR files for platform specific APIs For both GLib and GIO. (GObject, GIRepository and GModule don’t have any platform specific APIs.) This is needed for two reasons: * If the same GIR file is shipped on multiple platforms, it has no way to conditionally define/not-define an API based on the platform (like an `#ifdef` in a C header). So we either end up shipping differing GIR APIs on different platforms, or shipping a GIR file which declares APIs which aren’t resolvable by `dlopen()` on certain platforms, and will cause a language runtime error. * The API reference documentation is now generated from the GIR, and similar problems are present there: if the GIR contains different symbols depending on the platform, there is no way to generate API documentation for the union of all of them. The fix is to ensure that there are no conditional symbols in a GIR, by splitting out the platform specific symbols into platform specific GIR files. Platform specific documentation can then be generated from these, in addition to the main, platform agnostic, documentation. The documentation changes will following in a subsequent commit. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2024-02-06 16:29:30 +01:00
header: 'gio/gio.h',
includes: [ glib_gir[0], gmodule_gir[0], gobject_gir[0], gio_gir[0] ],
install: true,
girepository/introspection: correctly install .gir files into custom locations There is a meson option (gir_dir_prefix), but without being passed in here the files would always get installed into the default location (datadir). Signed-off-by: Alexander Kanavin <alex@linutronix.de>
2024-04-23 11:24:34 +02:00
install_dir_gir: glib_girdir,
introspection: Add libgirepository as a dep to all generate_gir() calls libgirepository is not needed by most of the modules, but it is needed by the `g-ir-scanner` generated dumper program. If we don’t explicitly include the local version of it here, Meson will implicitly link against it anyway, and that might pull in a different version, or try to link against a half-built local version as the build ordering dependency tree won’t reflect this relationship. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Fixes: #3401
2024-06-26 13:48:32 +02:00
dependencies: gi_gen_shared_dependencies + [
introspection: Generate separate GIR files for platform specific APIs For both GLib and GIO. (GObject, GIRepository and GModule don’t have any platform specific APIs.) This is needed for two reasons: * If the same GIR file is shipped on multiple platforms, it has no way to conditionally define/not-define an API based on the platform (like an `#ifdef` in a C header). So we either end up shipping differing GIR APIs on different platforms, or shipping a GIR file which declares APIs which aren’t resolvable by `dlopen()` on certain platforms, and will cause a language runtime error. * The API reference documentation is now generated from the GIR, and similar problems are present there: if the GIR contains different symbols depending on the platform, there is no way to generate API documentation for the union of all of them. The fix is to ensure that there are no conditional symbols in a GIR, by splitting out the platform specific symbols into platform specific GIR files. Platform specific documentation can then be generated from these, in addition to the main, platform agnostic, documentation. The documentation changes will following in a subsequent commit. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2024-02-06 16:29:30 +01:00
libglib_dep,
libgobject_dep,
libgmodule_dep,
],
env: gi_gen_env_variables,
introspection: Drop Unix and Win32 prefixes from platform specific APIs 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
2024-02-09 00:58:26 +01:00
extra_args: gir_args + gio_gir_args + gio_win32_gir_c_includes + [
introspection: Correct GIO-Windows pkg-config name It's gio-windows-2.0.pc, not gio-win32-2.0.pc. Otherwise, we get warnings/errors where the package cannot be located but since we are linking to the same GIO library file, this did not manifest itself.
2024-07-17 10:25:43 +02:00
'--pkg=gio-windows-2.0',
introspection: Drop Unix and Win32 prefixes from platform specific APIs 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
2024-02-09 00:58:26 +01:00
'--symbol-prefix=g_win32',
'--identifier-prefix=GWin32'
],
introspection: Generate separate GIR files for platform specific APIs For both GLib and GIO. (GObject, GIRepository and GModule don’t have any platform specific APIs.) This is needed for two reasons: * If the same GIR file is shipped on multiple platforms, it has no way to conditionally define/not-define an API based on the platform (like an `#ifdef` in a C header). So we either end up shipping differing GIR APIs on different platforms, or shipping a GIR file which declares APIs which aren’t resolvable by `dlopen()` on certain platforms, and will cause a language runtime error. * The API reference documentation is now generated from the GIR, and similar problems are present there: if the GIR contains different symbols depending on the platform, there is no way to generate API documentation for the union of all of them. The fix is to ensure that there are no conditional symbols in a GIR, by splitting out the platform specific symbols into platform specific GIR files. Platform specific documentation can then be generated from these, in addition to the main, platform agnostic, documentation. The documentation changes will following in a subsequent commit. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2024-02-06 16:29:30 +01:00
)
girepository: Make gi_repository_find_by_gtype() deterministic When faced with a `GType` which is present in multiple typelibs, the old implementation was not deterministic, as it iterated over a hash table of typelibs. The iteration order of a hash table is not deterministic. Use the new `ordered_typelibs` and `ordered_lazy_typelibs` arrays to iterate instead, making the order deterministic. Add a unit test to check this. In particular, to check that symbols which are present in both `Gio` and `GioUnix` are correctly resolved as being from `GioUnix`. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3303
2024-05-02 17:03:24 +02:00
gio_platform_gir = gio_win32_gir
introspection: Generate separate GIR files for platform specific APIs For both GLib and GIO. (GObject, GIRepository and GModule don’t have any platform specific APIs.) This is needed for two reasons: * If the same GIR file is shipped on multiple platforms, it has no way to conditionally define/not-define an API based on the platform (like an `#ifdef` in a C header). So we either end up shipping differing GIR APIs on different platforms, or shipping a GIR file which declares APIs which aren’t resolvable by `dlopen()` on certain platforms, and will cause a language runtime error. * The API reference documentation is now generated from the GIR, and similar problems are present there: if the GIR contains different symbols depending on the platform, there is no way to generate API documentation for the union of all of them. The fix is to ensure that there are no conditional symbols in a GIR, by splitting out the platform specific symbols into platform specific GIR files. Platform specific documentation can then be generated from these, in addition to the main, platform agnostic, documentation. The documentation changes will following in a subsequent commit. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2024-02-06 16:29:30 +01:00
else
gio_unix_gir_c_includes = []
foreach h: gio_unix_include_headers
build: Bump Meson dependency to 1.4.0 Meson 1.5.1 is available in the fd.o SDK and in Debian testing, so the glib Meson policy says we can update. Update the minimum only as far as 1.4.0 because we don't yet have a need for 1.5.0. This allows us to: - Use file.full_path() to avoid deprecation warnings on str.format(file). - Set c_std=gnu99,c99 to avoid deprecation warnings with gnu99 on MSVC. Update all the CI builds to use the latest 1.4.x patch release, 1.4.2. The FreeBSD runner cannot be updated via `gitlab-ci.yml`, so will be broken for now. Similarly, the macOS build will not work unless `-Dc_std=gnu99` is specified at configure time, due to https://github.com/mesonbuild/meson/issues/13639.
2024-09-05 13:31:09 +02:00
gio_unix_gir_c_includes += '--c-include=' + h.full_path()
introspection: Generate separate GIR files for platform specific APIs For both GLib and GIO. (GObject, GIRepository and GModule don’t have any platform specific APIs.) This is needed for two reasons: * If the same GIR file is shipped on multiple platforms, it has no way to conditionally define/not-define an API based on the platform (like an `#ifdef` in a C header). So we either end up shipping differing GIR APIs on different platforms, or shipping a GIR file which declares APIs which aren’t resolvable by `dlopen()` on certain platforms, and will cause a language runtime error. * The API reference documentation is now generated from the GIR, and similar problems are present there: if the GIR contains different symbols depending on the platform, there is no way to generate API documentation for the union of all of them. The fix is to ensure that there are no conditional symbols in a GIR, by splitting out the platform specific symbols into platform specific GIR files. Platform specific documentation can then be generated from these, in addition to the main, platform agnostic, documentation. The documentation changes will following in a subsequent commit. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2024-02-06 16:29:30 +01:00
endforeach
gio_unix_gir = gnome.generate_gir(libgio,
sources: gio_unix_include_headers + unix_sources,
namespace: 'GioUnix',
nsversion: '2.0',
identifier_prefix: gi_identifier_prefix,
symbol_prefix: gi_symbol_prefix,
export_packages: [ 'gio-unix-2.0' ],
header: 'gio/gio.h',
includes: [ glib_gir[0], gmodule_gir[0], gobject_gir[0], gio_gir[0] ],
install: true,
girepository/introspection: correctly install .gir files into custom locations There is a meson option (gir_dir_prefix), but without being passed in here the files would always get installed into the default location (datadir). Signed-off-by: Alexander Kanavin <alex@linutronix.de>
2024-04-23 11:24:34 +02:00
install_dir_gir: glib_girdir,
introspection: Add libgirepository as a dep to all generate_gir() calls libgirepository is not needed by most of the modules, but it is needed by the `g-ir-scanner` generated dumper program. If we don’t explicitly include the local version of it here, Meson will implicitly link against it anyway, and that might pull in a different version, or try to link against a half-built local version as the build ordering dependency tree won’t reflect this relationship. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Fixes: #3401
2024-06-26 13:48:32 +02:00
dependencies: gi_gen_shared_dependencies + [
introspection: Generate separate GIR files for platform specific APIs For both GLib and GIO. (GObject, GIRepository and GModule don’t have any platform specific APIs.) This is needed for two reasons: * If the same GIR file is shipped on multiple platforms, it has no way to conditionally define/not-define an API based on the platform (like an `#ifdef` in a C header). So we either end up shipping differing GIR APIs on different platforms, or shipping a GIR file which declares APIs which aren’t resolvable by `dlopen()` on certain platforms, and will cause a language runtime error. * The API reference documentation is now generated from the GIR, and similar problems are present there: if the GIR contains different symbols depending on the platform, there is no way to generate API documentation for the union of all of them. The fix is to ensure that there are no conditional symbols in a GIR, by splitting out the platform specific symbols into platform specific GIR files. Platform specific documentation can then be generated from these, in addition to the main, platform agnostic, documentation. The documentation changes will following in a subsequent commit. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2024-02-06 16:29:30 +01:00
libglib_dep,
libgobject_dep,
libgmodule_dep,
],
env: gi_gen_env_variables,
introspection: Drop Unix and Win32 prefixes from platform specific APIs 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
2024-02-09 00:58:26 +01:00
extra_args: gir_args + gio_gir_args + gio_unix_gir_c_includes + [
'--pkg=gio-unix-2.0',
'--symbol-prefix=g_unix',
'--identifier-prefix=GUnix'
],
introspection: Generate separate GIR files for platform specific APIs For both GLib and GIO. (GObject, GIRepository and GModule don’t have any platform specific APIs.) This is needed for two reasons: * If the same GIR file is shipped on multiple platforms, it has no way to conditionally define/not-define an API based on the platform (like an `#ifdef` in a C header). So we either end up shipping differing GIR APIs on different platforms, or shipping a GIR file which declares APIs which aren’t resolvable by `dlopen()` on certain platforms, and will cause a language runtime error. * The API reference documentation is now generated from the GIR, and similar problems are present there: if the GIR contains different symbols depending on the platform, there is no way to generate API documentation for the union of all of them. The fix is to ensure that there are no conditional symbols in a GIR, by splitting out the platform specific symbols into platform specific GIR files. Platform specific documentation can then be generated from these, in addition to the main, platform agnostic, documentation. The documentation changes will following in a subsequent commit. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2024-02-06 16:29:30 +01:00
)
girepository: Make gi_repository_find_by_gtype() deterministic When faced with a `GType` which is present in multiple typelibs, the old implementation was not deterministic, as it iterated over a hash table of typelibs. The iteration order of a hash table is not deterministic. Use the new `ordered_typelibs` and `ordered_lazy_typelibs` arrays to iterate instead, making the order deterministic. Add a unit test to check this. In particular, to check that symbols which are present in both `Gio` and `GioUnix` are correctly resolved as being from `GioUnix`. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3303
2024-05-02 17:03:24 +02:00
gio_platform_gir = gio_unix_gir
introspection: Generate separate GIR files for platform specific APIs For both GLib and GIO. (GObject, GIRepository and GModule don’t have any platform specific APIs.) This is needed for two reasons: * If the same GIR file is shipped on multiple platforms, it has no way to conditionally define/not-define an API based on the platform (like an `#ifdef` in a C header). So we either end up shipping differing GIR APIs on different platforms, or shipping a GIR file which declares APIs which aren’t resolvable by `dlopen()` on certain platforms, and will cause a language runtime error. * The API reference documentation is now generated from the GIR, and similar problems are present there: if the GIR contains different symbols depending on the platform, there is no way to generate API documentation for the union of all of them. The fix is to ensure that there are no conditional symbols in a GIR, by splitting out the platform specific symbols into platform specific GIR files. Platform specific documentation can then be generated from these, in addition to the main, platform agnostic, documentation. The documentation changes will following in a subsequent commit. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Helps: #3037
2024-02-06 16:29:30 +01:00
endif
# GIRepository
girepository: Move GIR generation into girepository and prior to tests To enable tests which depend on libgirepository's GIR and typelib, we need to refactor the order we're currently building these items. We can also move everything under girepository/ to cleanup the top-level.
2024-01-26 10:32:10 +01:00
libgirepository_gir_sources = [
gi_visibility_h,
girepo_headers,
girepo_sources,
]
libgirepository_gir_packages = [ 'girepository-2.0' ]
libgirepository_gir_args = [
'-DGI_COMPILATION',
'--symbol-prefix=gi',
'--identifier-prefix=GI',
]
Introspection: Fix running g-ir-scanner 1.80.x+ on Windows Since we are now building introspection files for GLib while building GLib, so we want to make sure that we indeed load the freshly-built DLLs when running g-ir-scanner, so we add the various needed subdirs (and if needed, subprojects), to set the GI_EXTRA_BASE_DLL_DIRS envvar so that g-ir-scanner will look for the newly-built GLib DLLs. Ideally, upstream g-ir-scanner will need to be updated accordingly to do something similar to what we are doing here, but this is needed until the time that we require a g-ir-scanner that contains the update. This will also fix the g-ir-scanner erroring out when there is no pre-existing GLib on the system, as the needed DLLs are now found. Related issue: https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/499 Related MR in G-I: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/458
2024-03-28 11:36:41 +01:00
gi_libgirepository_gen_env_variables = environment()
if host_system == 'windows'
gi_libgirepository_gen_env_variables.set('GI_EXTRA_BASE_DLL_DIRS', gi_scanner_dll_paths)
endif
girepository: Move GIR generation into girepository and prior to tests To enable tests which depend on libgirepository's GIR and typelib, we need to refactor the order we're currently building these items. We can also move everything under girepository/ to cleanup the top-level.
2024-01-26 10:32:10 +01:00
girepository_gir = gnome.generate_gir(libgirepository,
sources: libgirepository_gir_sources,
namespace: 'GIRepository',
nsversion: '3.0',
identifier_prefix: 'GI',
symbol_prefix: 'gi',
export_packages: libgirepository_gir_packages,
header: 'girepository/girepository.h',
includes: [ glib_gir[0], gmodule_gir[0], gobject_gir[0], gio_gir[0] ],
install: true,
girepository/introspection: correctly install .gir files into custom locations There is a meson option (gir_dir_prefix), but without being passed in here the files would always get installed into the default location (datadir). Signed-off-by: Alexander Kanavin <alex@linutronix.de>
2024-04-23 11:24:34 +02:00
install_dir_gir: glib_girdir,
introspection: Add libgirepository as a dep to all generate_gir() calls libgirepository is not needed by most of the modules, but it is needed by the `g-ir-scanner` generated dumper program. If we don’t explicitly include the local version of it here, Meson will implicitly link against it anyway, and that might pull in a different version, or try to link against a half-built local version as the build ordering dependency tree won’t reflect this relationship. Signed-off-by: Philip Withnall <pwithnall@gnome.org> Fixes: #3401
2024-06-26 13:48:32 +02:00
dependencies: gi_gen_shared_dependencies + [
libglib_dep,
libgobject_dep,
libgmodule_dep,
libgio_dep,
],
girepository: Move GIR generation into girepository and prior to tests To enable tests which depend on libgirepository's GIR and typelib, we need to refactor the order we're currently building these items. We can also move everything under girepository/ to cleanup the top-level.
2024-01-26 10:32:10 +01:00
extra_args: gir_args + libgirepository_gir_args,
Introspection: Fix running g-ir-scanner 1.80.x+ on Windows Since we are now building introspection files for GLib while building GLib, so we want to make sure that we indeed load the freshly-built DLLs when running g-ir-scanner, so we add the various needed subdirs (and if needed, subprojects), to set the GI_EXTRA_BASE_DLL_DIRS envvar so that g-ir-scanner will look for the newly-built GLib DLLs. Ideally, upstream g-ir-scanner will need to be updated accordingly to do something similar to what we are doing here, but this is needed until the time that we require a g-ir-scanner that contains the update. This will also fix the g-ir-scanner erroring out when there is no pre-existing GLib on the system, as the needed DLLs are now found. Related issue: https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/499 Related MR in G-I: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/458
2024-03-28 11:36:41 +01:00
env: gi_libgirepository_gen_env_variables,
girepository: Move GIR generation into girepository and prior to tests To enable tests which depend on libgirepository's GIR and typelib, we need to refactor the order we're currently building these items. We can also move everything under girepository/ to cleanup the top-level.
2024-01-26 10:32:10 +01:00
)
Reference in New Issue Copy Permalink