| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
cElementTree was removed in Python 3.9 in favor of ElementTree,
which has used a fast, native implementation since Python 3.3.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1817649
Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
|
| |
| |
| |
| | |
Comparing floats directly doesn't always work on all architectures.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
parameters
Virtual functions may use input/output parameters but this is not currently
well handled by gjs, so adding test cases to gobject-introspection to verify
that virtual functions correctly receive valid input values and can return
them.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
| |
Closes: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/320
|
| |
|
|
|
|
|
|
|
|
|
| |
There is no way that non-GCC/CLang compilers will pass this test because the
source position will never match the position that is in
tests/scanner/Regress-1.0-expected.gir.
Fix this the fast way: define a macro according to the compiler check and
update the corresponding source position
|
| |
|
| |
|
|
|
|
|
|
|
| |
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."
|
| |
|
|
|
|
|
| |
Let the people know how _giscanner.pyd handles looking up for dependent DLLs
on Python 3.8.x or later on Windows.
|
|
|
|
|
|
| |
We may get drive letters and paths either in upper or lower cases
in Windows, which are actually no different. Ignore the cases
in this case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Python 3.8.x and later changed the way how dependent DLLs can be found for a
given Python module that depends on the presence of external, non-system DLLs,
for more fine-grained DLLs searching and loading, as well as for security
purposes, which required the use of os.add_dll_directory().
Thus, the scripts in scanner/ must be updated such that:
-We are able to find and load the GObject and GLib DLLs, at least, on
initialization, via the use of 'pkg-config --variable bindir', as we already
depend on the GLib DLLs. Note that since the gobject-2.0.pc file does not
have a 'bindir' entry, we use gio-2.0.pc instead to discover the bindir of the
GObject and GLib DLLs. Likewise, we use the same technique for pkg-config
files that are dependent upon when using g-ir-scanner (or friends) on items
that are higher up in the stack.
-We are able to find any other DLLs (e.g. non-GNOME DLLs such as ZLib) that
are dependent but are not found in the path(s) given by 'pkg-config --variable
bindir' with the envvar GI_EXTRA_BASE_DLL_DIRS, as needed. Note that
GI_EXTRA_BASE_DLL_DIRS can be multiple paths, and that the results from
'pkg-config --variable bindir' takes precendence, in a LIFO manner.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
The XML elements are implicitly iterable in all Python versions including
at least 2.7 and 3.2+.
The .getchildren() method is deprecated since 2.7 and 3.2, removed in 3.9.
Fixes https://gitlab.gnome.org/GNOME/gobject-introspection/issues/325
|
|
|
|
|
|
|
|
|
| |
See here:
https://gitlab.gnome.org/GNOME/gobject-introspection/merge_requests/64
Particularly, options are renamed to make it more readable and clear.
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
|
|
|
|
| |
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
By default LD_LIBRARY_PATH is set to the list of target library paths;
this breaks down in cross-compilation environment, as we need to run a
native emulation wrapper rather than the target binary itself. This patch
allows exporting those paths to a different environment variable
which can be picked up and used by the wrapper.
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
|
|
|
|
|
|
|
| |
This environment variable sets the location of sysroot directory in cross-compilation
environments; if the variable is not set, the prefix will be empty.
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
|
|
|
|
|
|
|
| |
This is useful in cross-compile environments where system's ldd
command does not work on binaries built for a different architecture
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
|
|
|
|
|
|
|
|
|
| |
With this option, giscanner will use a wrapper executable to run
binaries it's producing, instead of running them directly. This
is useful when binaries are cross-compiled and cannot be run directly,
but they can be run using for example QEMU emulation.
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
|
|
|
|
| |
warning: deprecated directive, use ‘%define parse.error verbose’
|
|
|
|
|
|
|
|
|
|
|
|
| |
ba744068 ("Make meson.override_find_program working on more complex use
cases") made the build no longer reproducible by encoding a build system
path into the output. This shouldn't be necessary anyway, since it
should be possible to add new paths to search for gir files by setting
the XDG_DATA_DIR environment variable.
Closes #318
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
In our case we have to do various special things in case glib isn't available
through pkg-config and not all tests are run.
Add a CI job that tests this case so we don't regress.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are notably 4 classes of GTypes where a girepository lookup
might fail:
- GTypes from private interfaces in public objects (eg. MetaCullable in
mutter)
- GTypes for private base objects with public interfaces (eg. GLocalFile
in GLib)
- GTypes registered from the language, and presumably not coming from the
GIR
- GTypes of objects/interfaces that we didn't load a typelib for
It is moot to look for those over and over again, and a full lookup can
be taxing if looking up for a method/property on objects with those
characteristics.
It seems we can cache the misses too, so next lookups are just as quick
as an introspected GType. The cache is invalidated after loading new
typelibs, in case some of the previously missed GTypes is now properly
introspected.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
prefix/datadir/libdir
The provided m4 macro uses pkg-config for setting INTROSPECTION_GIRDIR and INTROSPECTION_TYPELIBDIR
which can be used to install the generated gir/typelib files into. Up until now this always used
the prefix encoded in the g-i .pc file and ignored the prefix provided by the autotools project using it.
This can be fixed by passing "--define-variable=datadir=/mydatadir" to pkg-config. To get the real value of
datadir include a copy of AS_AC_EXPAND in our m4 and use it to expand the variables we need so we can
pass the real paths to pkg-config which will use them to generate the new girdir/typelibdir paths.
The reason this hasn't been much of a problem is that the example autotools code suggested using
"girdir = $(datadir)/gir-1.0" and "typelibsdir = $(libdir)/girepository-1.0" and not using the variables defined
by our macro, so not many projects used it. Now both ways should work.
See !133
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The libgirepository example now is its own meson project.
There now is a small library that is buildable with meson and autotools
which creates a gir/typelib. Usefull for testing our build system integration
and for small experiments.
Fixes #287
|
|
|
|
| |
See !186
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we save the macros to pass to distutils to compile the dumper
program, the quotes were not properly preserved for Visual Studio
builds, causing items such as -DG_LOG_DOMAIN to fail as quotes are used
in there.
When we use quotes in macro definitions, we escape the escape
character in ccompiler._set_cpp_options() when we are running
g-ir-scanner with Visual Studio, so that distutils won't be too eager
to drop those prematurely.
|
|
|
|
|
| |
The different dir separator seems to confuse meson now
(likely a new change in mingw Python path handling..)
|
|
|
|
|
|
|
|
| |
Check that g_object_info_get_ref_function_pointer() actually returns something,
which it doesn't if the shared lib isn't found.
In case a shared lib isn't found g-i will emit a warning, so also make sure
we fail on warnings to avoid similar problems in the future.
|
| |
|
| |
|
|
|
|
| |
In g_irepository_get_object_gtype_interfaces()
|
|
|
|
|
|
|
| |
Similar to !180 this should prevent devs from not running all tests by
accident.
This also adds some checks for the required doctool dependencies, mako and markdown.
|
|
|
|
|
|
|
|
|
| |
We require cairo only to run all tests and thus default it to false.
This usually results in developers not using it when working on changes and
tests depending on cairo then failing in CI.
This changes it to a feature option that defaults to auto, so that devs that
have cairo headers installed will automatically use it.
|