| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
'relocatable' at runtime.
https://bugzilla.gnome.org/show_bug.cgi?id=620566
|
| |
|
|
|
|
|
|
| |
'relocatable' at runtime.
https://bugzilla.gnome.org/show_bug.cgi?id=620566
|
|
|
|
|
|
|
|
|
| |
The "--code" option was removed years ago in ac81f3e8c5f1c380d16677232d67466e739da283
so remove references to it from README and g-ir-compiler(1)
Remove the "--no-init" option from g-ir-compiler and g-ir-compiler(1)
as it was documented to "can only be used if --code is also specified",
so no reason to keep it around.
|
|
|
|
| |
And bump our GLib requirement.
|
| |
|
|
|
|
|
|
|
|
|
| |
g-ir-scanner 'relocatable' at runtime."
It's a bit too soon for this one, misunderstood review on irc.
Apologies for the mess!
This reverts commit 0102c517c44d3e8fc3baf2394cb92281511941e3.
|
|
|
|
|
|
| |
'relocatable' at runtime.
https://bugzilla.gnome.org/show_bug.cgi?id=620566
|
| |
|