summaryrefslogtreecommitdiff
path: root/giscanner/dumper.py
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`
* Always pass an encoding to open() using text modeChristoph Reiter2020-11-071-2/+2
| | | | | | | | Otherwise we'll end up using the locale encoding. While it's usually utf-8, that's not the case on Windows. There is one place where a file with filenames is passed, not sure there so I left it and passed a explicit None.
* dumper: Fix missing symbols in LTO case or with overridden symbol visibility ↵Christoph Reiter2020-05-151-2/+2
| | | | | | | | | | | | | | | | | | | | settings In case a user had a combination of -fvisibility=hidden, -Wl,--as-needed, -flto, -O2 in the CFLAGS the linker would sometimes detect that all the referenced gtype functions weren't actually used and throw them out with their providing libraries. Instead of hoping that the user's CFLAGS don't mess without our symbol visibility just use G_MODULE_EXPORT on the two symbols which reference all other gtype and gquark symbols. This fixes errors such as: Invalid GType function: 'gtk_accel_group_get_type' Failed to find symbol 'gtk_accel_group_get_type' during the g-ir-scanner execution. Fixes #280
* 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.
* giscanner: add a --lib-dirs-envvar optionAlexander Kanavin2019-12-131-1/+2
| | | | | | | | | | 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>
* ccompiler: use the distutils linker in the dumperChristoph Reiter2019-08-081-5/+1
| | | | | No need to hardcode things since distutils looks it up. Similar to !170 but for Windows.
* Use the defined compiler when invoking libtoolDavid Demelier2019-08-081-1/+1
| | | | Closes: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/303
* Drop all Python 2 compat codeChristoph Reiter2018-12-081-5/+0
| | | | We only support 3.4+ now.
* tests: depend on flake8 instead of including pep8/pyflakesChristoph Reiter2018-08-151-1/+0
| | | | | | | | | | | | | | | | g-i includes an old version of pep8 and pyflakes and uses that during "make check". It (1) doesn't catch all cases newer versions of pycodestyle/pyflakes catch and (2) doesn't test all Python files (3) doesn't work with meson. Instead of updating just remove them and depend on flake8 instead. To run the checks simply run flake8 in the root dir. This also makes it possible to run those checks when using meson and not autotools. To not get test suite failures on flake8 updates move the checks from "make check" to an extra "make check.quality" target.
* Factor out pkg-config functionality to a separate module.Tomasz Miąsko2018-07-281-18/+6
| | | | | | | | | | | | | | Functional changes: * Consistently check that return code from pkg-config is zero. * Use shell word splitting rules to process pkg-config output to match behaviour obtained by running `cc program.cc $(pkg-config --cflags ...)`. Fixes issue #171 . * Use user preferred encoding to process output from pkg-config on Python 3. Python 2 behaviour defaults to using ascii encoding as before. edit creiter: still ignore pkg-config errors by default for now as we depend on it when glib is a subproject.
* dumper: use cflags passed through --cflags-begin/endChristoph Reiter2018-06-201-2/+3
| | | | | | | | | When GI is build without an installed glib and meson builds glib as a subproject the include paths are passed through --cflags-begin/end. The dumper didn't use them but worked anyway if glib was installed somewhere and pkg-config returned some cflags. This make the GI build work with meson without having glib installed.
* Add utils.rmtree() which waits and tries again if a file is still in useChristoph Reiter2018-06-201-3/+2
| | | | | | | | | | | | | | | On Windows the dumper cleanup regularely fails because the created .exe is still in use by some process and shutil.rmtree() fails with: OSError: [WinError 145] The directory is not empty I'm not 100% sure what's the cause for this, but searching for similar issues suggests that it might be Windows Defender scanning the newly created .exe file and because it's so short lifed the scanning and deleting conflict. This adds a helper which tries a few times and waits a bit before giving up. A similar patch has been in MSYS2 for some time: https://github.com/Alexpux/MINGW-packages/blob/d0c39af02a669e45272c713e912ee63b0dd94157/mingw-w64-gobject-introspection/0025-more-tolerant-rmtreeing.patch
* dumper: fix for Python 3Christoph Reiter2018-06-181-0/+2
| | | | The MSYS2 only code wasn't ported to Python 3 and failed with a TypeError
* g-ir-scanner: Don't require SRCDIR and BUILDDIR env varsNirbheek Chauhan2018-03-101-2/+5
| | | | | | | | | | | | | 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.
* Allow overriding of the host os nameNicola Fontana2018-01-251-1/+1
| | | | | | | | Added the GI_HOST_OS environment variable to eventually specify the host OS explicitely. It fall backs to os.name to retain backward compatibility. https://bugzilla.gnome.org/show_bug.cgi?id=761985
* giscanner: Do not use distutils for linkingChun-wei Fan2017-05-031-66/+39
| | | | | | | | | | | | | | | | | | | | | | | | ...the dumper program for all cases. It turned out that using distutils for linking is more troublesome than useful as we need to ensure that the paths specified by -L need to come before the standard library search paths, and distutil's ccompiler.add_library_path() and ccompiler.add_runtime_library_path() does not work for all of its supported compilers (Visual Studio is an example). Instead, we go back to constructing our linker command line manually as we did before (and as we now do in the libtool case), but with some enhancements: -Use '-libpath:' on Visual Studio builds, which corresponds to the -L flag on GCC/CLang. -Extend LIB/PATH (Windows/Visual Studio) or LD_LIBRARY_PATH (other compilers/envs), which is necessary as we resolve the libraries that are passed into g-ir-scanner, at least on Windows. -Don't attempt to link to or resolve m.lib on Visual Studio builds, as the math functions are in the standard CRT .lib/.dll, and there is no such thing as m.lib https://bugzilla.gnome.org/show_bug.cgi?id=781525
* g-ir-scanner: fix wrong order of -L options in libtool invocationSebastian Geiger2017-03-261-2/+4
| | | | | | | This patch fixes an issue in dumper.py, which causes a wrong oder of -L options to be passed to libtool. This in turn can cause build failures if old library files are present in the linked library directories. https://bugzilla.gnome.org/show_bug.cgi?id=778507
* giscanner: Use shlex.split() for environment variablesNirbheek Chauhan2017-03-211-6/+4
| | | | | | | | | | | | | | str.split() does not handle quoting, so if you have spaces in your CFLAGS, it will be split incorrectly. For instance: CFLAGS="'-I/opt/some dir' -DFOO=bar" >>> os.environ['CFLAGS'].split() ["'-I/opt/some", "dir'", '-DFOO=bar'] >>> shlex.split(os.environ['CFLAGS']) ['-I/opt/some dir', '-DFOO=bar'] https://bugzilla.gnome.org/show_bug.cgi?id=778971
* scanner: Add a way to specify extra libraries to link againstThibault Saunier2016-12-101-0/+1
| | | | | | | | | | | | Currently the only way to get a library to link against the dumper program is through '--link' which implies that library will be defined in the 'libraries' field of the .gir. When using libtool, we link against dependencies of that library as the .la defines that, but when using --no-libtool that won't happen and the user needs to be able to define to what other libraries the program needs to be link against, and this is what the new --extra-library argument is about. https://bugzilla.gnome.org/show_bug.cgi?id=774625
* giscanner/dumper.py: Fix for Python 3.x for MSVC 2010+Chun-wei Fan2015-10-281-1/+2
| | | | | | | | sys.exc_clear(), which was called when we need to ignore the error when we can't embed manifests to the dumper program on MSVC 2010 and later, is only available/needed for Python 2.7.x, so only use it there. https://bugzilla.gnome.org/show_bug.cgi?id=757126
* giscanner: Fix python2/3 compatibilityDamien Grassart2015-10-191-1/+1
| | | | | | | This allows building in both Python 2 and 3 by fixing a few text/binary ambiguities and using "as" in an except clause. https://bugzilla.gnome.org/show_bug.cgi?id=756763
* giscanner: Decode command output for Python 3 compatibilitySimon Feltman2015-09-291-1/+2
| | | | | | | Decode the output of various subprocess calls assuming ascii encoding. https://bugzilla.gnome.org/show_bug.cgi?id=679438
* giscanner: Use unicode literals in all Python filesSimon Feltman2015-09-291-0/+1
| | | | | | | | | | | | 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-2/+3
| | | | | | | 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-0/+2
| | | | | | Use absolute_import to ensure Python 3 compatibility of the code base. https://bugzilla.gnome.org/show_bug.cgi?id=679438
* giscanner: Use Distutils to Build Dumper ProgramChun-wei Fan2015-09-011-96/+91
| | | | | | | | | | | | | | | | | | | Add compile() and link() functions in ccompiler.py to call distutils.ccompiler's compiler() and link() functions, so that we can in turn call them from dumper.py as needed. Note that for linking the dumper program when building with libtool, we are still using the original method of constructing the link command line and running that command line, as distutils and libtool do not get along well with each other. For non-libtool builds, such as MSVC builds, we would link the dumper program using distutils. For MSVC builds, we need to ignore mt.exe failing to find a .exe.manifest file as Visual Studio 2010+ do not generate such files during linking, and it is done by distutils as Python 2.7.x is built with Visual Studio 2008, which do generate such manifest files during the build. https://bugzilla.gnome.org/show_bug.cgi?id=753428
* scanner: use open() as os.fdopen as context managersDieter Verfaillie2015-08-211-39/+36
| | | | | | Ensures files are correctly and immediately closed. https://bugzilla.gnome.org/show_bug.cgi?id=751926
* Revert "dumper.py: Use Distutils to Build Dumper Program"Chun-wei Fan2015-07-311-61/+127
| | | | | | | | | This reverts commit 7ce646db1cb0842db2089df671b17081f82f2b0a. Apparently this patch caused introspection build breakage for gnome-shell, as problems occurred during linking for libgnome-volume-control. Please see bug 728313 comment 105 for more details.
* dumper.py: Use Distutils to Build Dumper ProgramChun-wei Fan2015-07-301-127/+61
| | | | | | | | | | | | | | | | Add compiler() and link() functions in ccompiler.py to call distutil.ccompiler's compile() and link() functions, so that we can in turn call them from dumper.py to build the dumper program. As distutils don't get along well with libtool libraries (ie .la files), we can deduce the libraries to link from using the file name .la file and include $(builddir)/.libs in the linking stage. For MSVC builds, we need to ignore mt.exe failing to find a .exe.manifest file as Visual Studio 2010+ do not generate such files during linking, and it is done by distutils as Python 2.7.x is built with Visual Studio 2008, which do generate such manifest files during the build. https://bugzilla.gnome.org/show_bug.cgi?id=728313
* giscanner/ccompiler.py: Initiate Distutils Compiler InstanceChun-wei Fan2015-07-301-32/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | This updates the __init__ constructor method of CCompiler so that distutils can be used, with some environment or user-supplied options to create the compiler instance that is appropriate with the platform that the giscanner scripts are being run on, and sets some specific environment for the compilers as necessary. This also adds a check_is_msvc() method that will progressively replace calls in the other giscanner scripts that attempt to check for CC=cl (or so), where a part of which is done in this patch. This is done for dumper.py as well as it needs to be updated in this patch to use the updated ccompiler.py which uses distutils to initiate the compiler instance. Also, as we have been using the --library option on Windows to pass in the library (not DLL) to deduce the correct DLL to link to in the introspection files for some time, we no longer need to make a copy of the library (.lib) to introspect that matches the <namespace>-<namespace_version>.lib convention, but use the libraries that were passed in with --library directly, so that we can link the dumper program during the introspection build. Please note that this also partially reverts commit c9cfa2b as the distutils items are clearly needed for these to work. https://bugzilla.gnome.org/show_bug.cgi?id=728313
* giscanner: Add New CCompiler ModuleChun-wei Fan2014-08-051-71/+16
| | | | | | | | | | | | | | | This adds a CCompiler module for the giscanner Python scripts so that items related to the run of the preprocessor, compiler and linker can be done in this module, and this marks the beginning of the move of building the introspection files using Python's distutils. This patch first moves _add_[internal|external]_link_flags() to ccompiler.py as get_[internal|external]_link_flags and also moves the Windows shlibs resolution (deducing the DLLs the introspection files should link to from the libraries passed in) in shlibs.py to resolve_windows_libs() in ccompiler.py https://bugzilla.gnome.org/show_bug.cgi?id=728313
* scanner: Make sure .libs directory existsРуслан Ижбулатов2014-02-271-0/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=724882
* Fix some PEP8 errors from previous commitsColin Walters2014-02-221-2/+3
|
* Fix a typo (exe -> .exe)Руслан Ижбулатов2014-02-221-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=724884
* scanner: Correctly pass linker option --export-all-symbolsРуслан Ижбулатов2014-02-221-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=724883
* scanner: Support running under MSYSРуслан Ижбулатов2014-02-221-0/+15
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=724880
* Honour CPPFLAGS as we do CFLAGSRyan Lortie2013-12-211-0/+6
| | | | | | | In all of the places that we pass through the CFLAGS, we should be doing the same with the CPPFLAGS. https://bugzilla.gnome.org/show_bug.cgi?id=720063
* dumper: use 'cc' as the default C compilerRyan Lortie2013-12-081-1/+1
| | | | | | | | If $(CC) is unset, use 'cc' instead of 'gcc' as the default compiler. This matches the behaviour used in the source scanner. https://bugzilla.gnome.org/show_bug.cgi?id=720066
* giscanner: Make sure we use real paths in more placesCarlos Garcia Campos2013-11-151-1/+1
| | | | | | | | Ensure we are using the real path also for cflags comming from pkg_config files and command line options. This fixes the generation of the gir files when include paths contain symlinks. https://bugzilla.gnome.org/show_bug.cgi?id=712211
* dumper: Attempt to identify MSVC/'cl' more preciselyColin Walters2013-08-221-3/+3
| | | | | | | | | Checking for 'cl' in the whole compiler string trips up people who do CC='gcc --command-with-cl-in-the-name'. We should (probably) only look at the first argument, although this will break for people doing CC='ccache cl', but would someone do that? See: https://bugzilla.gnome.org/show_bug.cgi?id=698090
* tests: Update misc/pep8.py to 1.4.5Dieter Verfaillie2013-05-071-6/+7
| | | | | | | | | | | | | | | | | Version in our tree is a wee bit outdated. For example, later work will introduce an utf8 encoded python source file which our old pep8.py does not yet understand (yeah, it really was *that* ancient)... Updated from: https://raw.github.com/jcrocholl/pep8/1.4.5/pep8.py Takes 552c1f1525e37a30376790151c1ba437776682c5, f941537d1c0a40f0906490ed160db6c79af572d3, 5a4afe2a77d0ff7d9fea13dd93c3304a6ca993de and a17f157e19bd6792c00321c8020dca5e5a281f45 into account... https://bugzilla.gnome.org/show_bug.cgi?id=699535
* giscanner: Fix for PEP-8 style checkRico Tzschichholz2013-05-031-1/+2
|
* Fix scanning libraries with no GObjects and linker using --as-neededRobert Ancell2013-05-021-0/+4
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=699442
* Do not misdetect clang as the Microsoft C compilerEmmanuele Bassi2013-05-011-2/+3
| | | | | | Just because they both start with 'cl'. https://bugzilla.gnome.org/show_bug.cgi?id=698090
* giscanner: prefer "except X as e" over "except X, e"Dieter Verfaillie2013-04-091-4/+4
| | | | | | It's more readable and as an added bonus Python 3 compatible. https://bugzilla.gnome.org/show_bug.cgi?id=697616
* dumper.py: Fix for Visual C++ usageChun-wei Fan2013-02-221-1/+6
| | | | | | | -Wno-deprecated-declarations is a compilation flag that causes builds of introspection files to fail on Visual C++ builds, so use -wd4996 instead when we are using Visual C++, which serves the same purpose of -Wno-deprecated-declarations with Visual C++.
* giscanner: Suppress deprecation warnings when introspecting typesStef Walter2013-02-131-0/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=693742
* giscanner/dumper.py: Support Visual C++Chun-wei Fan2012-10-271-22/+72
| | | | | | | | | | | | | -Pass the --msvc-syntax flag to pkg-config when Visual C++ is used. -Use .obj instead of .o filename extension when running on Visual C++, as that is the default object file name extension on visual C++. -Specify compiler output flags for Visual C++. -Avoid using -Wl and -rpath on Visual C++, and link to .lib files instead when generating a .gir file within the package. -Avoid unecessary linking under Visual C++ to the .dll files since we already linked to the corresponding .lib files. https://bugzilla.gnome.org/show_bug.cgi?id=681820
* Drop calls to g_type_init()Colin Walters2012-10-161-0/+2
| | | | And bump our GLib requirement.
View Lorry Controller Status