summaryrefslogtreecommitdiff
path: root/tools/g-ir-tool-template.in
Commit message (Collapse)AuthorAgeFilesLines
* Make test suite work with cross-related optionsJohn Ericson2021-05-231-1/+1
| | | | | | | | | | Because of skepticism I received in #224, I made this PR which keeps the testsuite and CI improvements but doesn't add any new build options. I hope this would be less controversial: - no new knobs - tests for those using existing build options - CI tests `build_introspection_data = false`
* Remove old autoconf fallback code for the python tools.John Ericson2020-05-171-7/+2
|
* Windows: Fix building and running on Python 3.8+Chun-wei Fan2020-01-161-0/+4
| | | | | | | | | | | | | | | | | | | | | | | 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.
* Make meson.override_find_program working on more complex use casesThibault Saunier2019-08-151-1/+2
| | | | | | | 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`.
* Drop all Python 2 compat codeChristoph Reiter2018-12-081-8/+1
| | | | We only support 3.4+ now.
* g-ir-tools: respect gir_dir_prefixKai Kang2018-10-081-0/+10
| | | | | | | | | 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>
* g-ir-tool: ask sysconfig instead of hardcoding the extension module suffixChristoph Reiter2018-08-211-4/+4
| | | | | MinGW Python doesn't use .pyd so this makes sure we always look for the file distutils produces for the given Python setup.
* g-ir-tool-template.in: Don't hardcode /usr/bin/envChun-wei Fan2018-08-211-1/+1
| | | | | | | | | | | | | | | 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.
* g-ir-tool-templates.in: Fix installed use on WindowsChun-wei Fan2018-08-201-1/+6
| | | | | | | 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.
* g-ir-tool-template: Add correct path to _giscanner.so on autotoolsRico Tzschichholz2018-03-101-1/+1
| | | | | This fixed make check and was a regression of 9b41d08057ed1ee2f4ce3a733413a8b2ad5a98d8
* g-ir-scanner: Don't require SRCDIR and BUILDDIR env varsNirbheek Chauhan2018-03-101-12/+33
| | | | | | | | | | | | | 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.
* Initial work on meson portPatrick Griffis2018-03-101-0/+4
|
* g-ir-tool-template: Fix a coding error that hooks up pdb in any buildMikhail Zabaluev2015-11-011-2/+2
| | | | | | | | | 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
* tools: Windows-re-enable 'relocatability' for tool templateChun-wei Fan2015-10-281-2/+2
| | | | | | | | 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
* giscanner: Use builtins module in Python 3Simon Feltman2015-09-291-2/+6
| | | | | | Add conditional import for Python 3's renamed builtins module. https://bugzilla.gnome.org/show_bug.cgi?id=679438
* giscanner: Use unicode literals in all Python filesSimon Feltman2015-09-291-0/+2
| | | | | | | | | | | | 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
* giscanner: Use print as a function for Python 3 compatibilitySimon Feltman2015-09-291-1/+2
| | | | | | | 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
* giscanner: Enable "true division" for all Python filesSimon Feltman2015-09-291-0/+1
| | | | | | | | | | 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
* giscanner: Use absolute_import for all Python filesSimon Feltman2015-09-291-1/+1
| | | | | | Use absolute_import to ensure Python 3 compatibility of the code base. https://bugzilla.gnome.org/show_bug.cgi?id=679438
* tools: use a template to generate the tools scriptsDieter Verfaillie2015-06-291-0/+58
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.
View Lorry Controller Status