| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Add some missing `meson.override_find_program`
And make sure that the `.gir` we build are found when used uninstalled
as a concequence of `meson.override_find_program`.
|
|
|
|
|
|
|
|
|
|
| |
In our case it was never needed because it defaults to true if install_dir is set,
which it always is for all calls.
This avoids a warning when running with newer meson where it complains that install
is only available with 0.50+.
Fixes #298
|
|
|
|
|
|
|
|
|
|
| |
By doing so, we essentially cover the various compiler flags that we
want to use for non-Visual Studio builds to check for warnings that
might cause real concern.
This also skips the checks for the various GCC-isque CFlag checks that
are scattered in the various build files on Visual Studio builds, since
they are essentially meaningless on Visual Studio builds.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This enables various compiler warnings project wide and disables the triggered
ones for each library/executable. This should give us roughly the same behaviour
as with autotools.
Tested with gcc8 and clang7.
|
|
|
|
| |
Removes a warning on an unreplaced pattern.
|
|
|
|
| |
We only support 3.4+ now.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From nirbheek:
"The shebang parsing goes like this: everything before the first space is
the interpreter, everything after that is a single argument to that
interpreter. So in meson, if the interpreter in the shebang is `env`,
we ignore it and slurp the rest as the actual interpreter and parse it
with shell syntax to handle spaces correctly.
IIRC the py.exe python launcher on windows also knows that it should
ignore /usr/bin/env and look at the rest to find the actual interpreter
you want to use."
|
|
|
|
|
|
|
|
|
| |
Configure option gir_dir_prefix is used to configure install dir for
.gir files, so add its value to include file search paths.
Fix for flake8 and meson-test at same time.
Signed-off-by: Kai Kang <kai.kang@windriver.com>
|
|
|
|
|
| |
MinGW Python doesn't use .pyd so this makes sure we always look for the
file distutils produces for the given Python setup.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For Visual Studio builds, it is likely that we specify a specific Python
installation as there may well be multiple Python installations, but
_giscanner.pyd gets tied to the particular Python DLL that it was built
with. So, we cannot just use /usr/bin/env python3 in such a case on
Visual Studio, but instead we use the full path to the Python executable
in the shebang so that the correct Python installation is used, when
running the installed scripts. This is necessary as Meson could bump
the Python version it requires but _giscanner.pyd could not be used on
the newer Python that is required due to differences in the Python
version and the CRT Python itself is linked to, for instance.
We continue to use /usr/bin/env python[2|3] for other builds.
|
|
|
|
|
|
|
| |
The .so file extension for compiled C Python modules is only valid if we
are not on Windows. Use .pyd for the extension for Python modules on
Windows so that we can use g-ir-scanner et al properly on Windows when
installed.
|
| |
|
|
|
|
| |
The error arg was used but the result never checked.
|
|
|
|
| |
So that meson projects using gi as a subproject can find them.
|
|
|
|
|
| |
So we end up using the same version as glib will be using.
See glib!187.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
It's not used and not distributed. If someone needs it, it's in git.
|
| |
|
|
|
|
|
| |
This fixed make check and was a regression of
9b41d08057ed1ee2f4ce3a733413a8b2ad5a98d8
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit f473d3b3ede94639f8d68fe618cc4cd287053181.
This can cause Meson to run g-ir-scanner with the wrong python; for
instance if you built gobject-introspection with a 64-bit Python but
you have a 32-bit Python in your PATH.
The correct fix is https://github.com/mesonbuild/meson/pull/2708.
|
|
|
|
|
|
| |
If there is a space in the path to python, we cannot use it in the
shebang since there is no way to quote spaces. Use the basename
instead since we pass it to /usr/bin/env anyway.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
We did not yet advertise C99 requirements for G-I yet, so let's not
assume this yet.
|
|
|
|
|
|
| |
It is required to correctly show translated messages on some locales.
https://bugzilla.gnome.org/show_bug.cgi?id=760419
|
|
|
|
|
|
| |
Reported-and-tested-by: Dominique Leuenberger <dimstar@opensuse.org>
Signed-off-by: Igor Gnatenko <ignatenko@src.gnome.org>
Reviewed-by: Colin Walters <walters@verbum.org>
|
|
|
|
|
|
| |
Signed-off-by: Igor Gnatenko <ignatenko@src.gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=769600
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Various distributions (mainly RPM based so far) make use of automatic
dependencies extracted from typelib files (they can require other typelibs
and also shared libraries)
Current features
* Print used shared libraries
* Print used typelib dependencies
Based-on-patch-by: Dominique Leuenberger <dimstar@opensuse.org>
Reference: https://bugzilla.gnome.org/show_bug.cgi?id=665672
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Dominique Leuenberger <dimstar@opensuse.org>
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
|
|
|
|
|
|
|
|
|
| |
A condition was supposed to test if GI_SCANNER_DEBUG environment
variable is unset or empty, but instead always evaluated to true.
This results in any build pausing in pdb whenever an uncaught exception
occurs in a g-ir-* tool.
https://bugzilla.gnome.org/show_bug.cgi?id=757443
|
|
|
|
|
|
|
|
| |
The transition to Python 3.x compatibility accidentily removed the
'relocatability' support that was added, so re-enable this support on
Windows again.
https://bugzilla.gnome.org/show_bug.cgi?id=757126
|
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=744535
Signed-off-by: Garrett Regier <garrett.regier@riftio.com>
|
|
|
|
|
|
| |
Add conditional import for Python 3's renamed builtins module.
https://bugzilla.gnome.org/show_bug.cgi?id=679438
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add unicode_literals future import which turns any string literal
into a unicode string. Return unicode strings from the Python C extension
module. Force writing of annotations (g-ir-annotation-tool) to output utf8
encoded data to stdout.
This is an initial pass at following the "unicode sandwich"
model of programming (http://nedbatchelder.com/text/unipain.html)
needed for supporting Python 3.
https://bugzilla.gnome.org/show_bug.cgi?id=679438
|
|
|
|
|
|
|
| |
Use future import "print_function" and update relevant uses of print
as a function call. See: PEP 3105
https://bugzilla.gnome.org/show_bug.cgi?id=679438
|
|
|
|
|
|
|
|
|
|
| |
Import Python 3 compatible "true division" from the future (PEP 238).
This changes the Python 2 classic division which uses floor division
on integers to true division. Verfied we don't actually use the
division operator anywhere in the code base so this a safety for
supporting both Python 2 and 3.
https://bugzilla.gnome.org/show_bug.cgi?id=679438
|
|
|
|
|
|
| |
Use absolute_import to ensure Python 3 compatibility of the code base.
https://bugzilla.gnome.org/show_bug.cgi?id=679438
|
|
|
|
|
|
|
|
| |
Otherwise the error is "no input files" which is very confusing.
https://bugzilla.gnome.org/show_bug.cgi?id=753160
Signed-off-by: Ben Boeckel <mathstuf@gmail.com>
|
|
|
|
| |
... so it lives next to the rest of the maintainer utilities.
|
|
|
|
|
|
| |
g-ir-annotation-tool, g-ir-doc-tool and g-ir-scanner where identical
except for the module and function being invoked.
Avoid code duplication and generate these from a common template.
|
| |
|