summaryrefslogtreecommitdiff
path: root/giscanner
Commit message (Collapse)AuthorAgeFilesLines
* giscanner: Fix minor python3 compatibility issueNirbheek Chauhan2018-03-101-1/+1
| | | | | | dict.items() returns a tuple in Python2 but it returns an iterator in Python3. This is usually fine, except that in this place we also try to index the return value which won't work with iterators.
* giscanner: Fix GtkDocAnnotations implementationNirbheek Chauhan2018-03-101-4/+4
| | | | | | | | Lesson to be learnt: *NEVER* have a try..except block that catches all exceptions and turns them into warnings that are silenced by default. There was a syntax error in this class implementation that made all annotation parsing fail silently.
* meson: Fix including of config.hNirbheek Chauhan2018-03-101-0/+2
| | | | | | We must use include_directories: to pass that so that it's not overriden by include paths from internal dependencies which will very commonly also have their own config.h in one of their include paths.
* meson: Use symbol visibility for giscanner moduleEmmanuele Bassi2018-03-102-2/+2
| | | | | | | | Remove the existing TODO and avoid playing games with the linker. We already have a mechanism in place for controlling he visibility of our symbols. Signed-off-by: Nirbheek Chauhan <nirbheek@centricular.com>
* giscanner: Fix options in the preprocessor groupNirbheek Chauhan2018-03-101-4/+7
| | | | | | | | | | | | | The way we were parsing cflags was causing cpp_includes, cpp_defines, cpp_undefines to always be empty because we would consume all arguments with --cflags-begin's callback. Now, we make a copy of the 'remaining arguments' and parse those to populate the cflags independent of cpp_* flags that are used for building the scanner executable. This fixes the build when glib and friends aren't available in the system prefix.
* meson: Try to use win_flex and win_bison if availableNirbheek Chauhan2018-03-101-2/+2
| | | | These are the native windows versions of flex and bison.
* g-ir-scanner: Don't require SRCDIR and BUILDDIR env varsNirbheek Chauhan2018-03-102-6/+18
| | | | | | | | | | | | | 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.
* giscanner: Remove custom collections implementationNirbheek Chauhan2018-03-108-476/+6
| | | | | | | We already require python 2.7, and it has OrderedDict and Counter. Besides cleaning up unmaintained code, this change found and fixed a Python 3 bug where we were iterating over a dict while changing it.
* meson: Use glib_dep and configinc for girepositoryNirbheek Chauhan2018-03-101-5/+3
| | | | | | glib_dep is what is actually needed to #include <glib.h>, not gobject_dep. It works incidentally with system gobject/glib but not when built via subprojects.
* Fix dependency on giscanner's python modulePatrick Griffis2018-03-101-1/+1
|
* Windows: compile with /DYY_NO_UNISTD_HDanny 'Guru' Forghieri2018-03-101-0/+6
|
* Initial work on meson portPatrick Griffis2018-03-101-0/+74
|
* Create a new symbol instead of changing its identifier in place.Tomasz Miąsko2018-02-131-2/+8
| | | | Also free memory associated with macro name when it is unused.
* Reuse const_table between calls to SourceScanner parse_files and parse_macros.Tomasz Miąsko2018-02-133-11/+7
| | | | | | | | Macro constants may now refer to constants defined in source files. Test case provided by Philip Chimento. Fixes issues #173 and #75.
* Fix parsing when type_specifier comes before type_qualifier.Tomasz Miąsko2018-02-091-2/+25
| | | | | | | | | | | | | | | | If type_specifier comes after type_qualifier, then GISourceType representing type_specifier will be merely updated with qualifier flags. On the other hand, when this order is reversed the type qualifier used to be attached as a separate node through base_type (with CTYPE_INVALID), and interpreted incorrectly in transformer code. This commit changes this behaviour so that information about type qualifiers is stored directly in GISourceType corresponding to type specifier. It also fixes analogous issue with storage_class_specifier and function_specifier. From higher level viewpoint, it for example represents `const char*` and `char const*` in equivalent manner after parsing, and addresses issue #79.
* Preserve complete_ctype when using type from annotation.Tomasz Miąsko2018-02-091-0/+1
| | | | | | | | When replacing type with one from user annotation we already preserve ctype, do the same for complete_ctype to preserve const / volatile qualifiers if any. Fixes issue #190.
* giscanner: don't print "suppressed N warnings" if --quiet was specifiedTim-Philipp Müller2018-02-081-1/+1
|
* Allow overriding of the host os nameNicola Fontana2018-01-253-3/+7
| | | | | | | | 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
* scanner: Fix library lookup under MinGW without libtoolChristoph Reiter2018-01-231-2/+3
| | | | | | | | | | | | | | | When executing the scanner binary use the PATH/LIB env vars also under MinGW, since LD_LIBRARY_PATH/rpath doesn't work there. When resolving the library name from the import library look into the user provided library paths first before falling back to the default gcc search path. This fixes the gir/typelib generation for meson under MSYS2. Note that MSYS2 ships various patches, so this might not fix it for all MinGW users. https://bugzilla.gnome.org/show_bug.cgi?id=791902
* giscanner: Fix shared library name finding on *BSDTing-Wei Lan2018-01-091-0/+5
| | | | | | | | ldd commands on *BSD always print the name of the input file regardless of the number of arguments, so we have to ignore this line to avoid matching it with _ldd_library_pattern. https://bugzilla.gnome.org/show_bug.cgi?id=791991
* giscanner: Recognize _Thread_local as a storage class specifierTing-Wei Lan2018-01-094-3/+11
| | | | | | | | | _Thread_local is a C11 keyword, and thread_local is a macro to make it more confortable to read. As this keyword can only be used in variable declarations, not in function return values or parameters, it cannot be included in bindable APIs and we can safely ignore it. https://bugzilla.gnome.org/show_bug.cgi?id=756921
* scanner: Add _Float128Emmanuele Bassi2017-12-211-1/+1
| | | | | | | | | The ISO/IEC TS 18661-3:2015 standard added new floating point types to the C standard. Newer versions of the GNU C library started exposing `_Float128` in the headers, which means we need to add this type to the known tokens, to avoid warnings.
* giscanner: fix EOF check with flex >= 2.6.1Jan de Groot2017-09-101-6/+15
| | | | | | | | | | It looks like flex 2.6.1 changed [1] the return code for EOF in yyinput. Therefore, use the right value depending on the version of flex which generates the lexer. [1] https://github.com/westes/flex/commit/f863c9490e6912ffcaeb12965fb3a567a10745ff https://bugzilla.gnome.org/show_bug.cgi?id=773272
* Ignore _Nonnull,_Nullable and _Null_unspecified type qualifiersDavid Lechner2017-09-031-0/+3
| | | | | | | These qualifiers are present in header files on macOS (introduced in XCode 7). https://bugzilla.gnome.org/show_bug.cgi?id=784458
* When handling errors according to errno, catch both IOError and OSErrorSimon McVittie2017-06-192-16/+10
| | | | | | | | | | | | | | | | | | | | | | | | Different Python versions are not completely consistent about the error that is raised and its class hierarchy: Python 3.5.3rc1 (default, Jan 3 2017, 04:40:57) >>> try: open('/foo') ... except Exception as e: print(e.__class__.__mro__) (<class 'FileNotFoundError'>, <class 'OSError'>, <class 'Exception'>, <class 'BaseException'>, <class 'object'>) Python 2.7.13 (default, Dec 18 2016, 20:19:42) >>> try: open('/foo') ... except Exception as e: print e.__class__.__mro (<type 'exceptions.IOError'>, <type 'exceptions.EnvironmentError'>, <type 'exceptions.StandardError'>, <type 'exceptions.Exception'>, <type 'exceptions.BaseException'>, <type 'object'>) This can lead to a race condition during cache cleaning, where two processes both try to delete the same file, and the one that loses the race fails. Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Iain Lane <laney@ubuntu.com> Reviewed-by: Colin Walters <walters@verbum.org> Bug: https://bugzilla.gnome.org/show_bug.cgi?id=772173
* giscanner/utils.py: Fix on non-UNIX-like platformsChun-wei Fan2017-06-151-1/+1
| | | | | | | | | | Commit 85b1d70b93211415d975deff6050f1401743e72d changed the null device from the platform-independent os.devnull to the UNIX /dev/null, which broke introspection builds on non-UNIX-like platforms, as /dev/null is a notion that does not exist on those platforms. Fix this by changing back to os.devnull, but still opening it as writable. https://bugzilla.gnome.org/show_bug.cgi?id=781312
* scanner: Fix non-libtool linker flags on DarwinPhilip Chimento2017-05-171-1/+1
| | | | | | | | | Darwin's linker doesn't like "-rpath=path"; instead pass "-rpath path", which works on more linkers than the version with the = sign does. Regressed in commit 5d4cd25292b8ed2c7a821ebe19fc5ab5d447db1a. https://bugzilla.gnome.org/show_bug.cgi?id=781525
* giscanner: Do not use distutils for linkingChun-wei Fan2017-05-032-115/+86
| | | | | | | | | | | | | | | | | | | | | | | | ...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
* giscanner: Update location of temp sources and objectsChun-wei Fan2017-05-012-3/+4
| | | | | | | | | | | | | | For preprocessing, when we create the temp file for preprocessing, make the temp file be stored in CWD instead of the system's temp directory; and when we compile the dumper program, set the output_dir to be the root directory (<drive letter>:\ on Windows and / otherwise). This is because distutils insists on using the full path from the root directory to compile sources, so that if we set the output_dir as we now do we will get $(abs_srcdir)/$(tmpdir)/<$(abs_srcdir)_minus_rootdir>/$(tmpdir)/<target_gir_file_name>.[o|obj]. https://bugzilla.gnome.org/show_bug.cgi?id=781525
* scannerparser.y: Really remove temp .h file on WindowsChun-wei Fan2017-05-011-1/+2
| | | | | | | | | | | | | In gi_source_scanner_parse_macros(), a temporary .h file is generated during the process of parsing the macros, and they aren't being deleted on Windows. In turns out that the g_unlink() call in that function failed because Windows does not allow one to unlink/delete files while they are open, and that the g_unlink() call is done way early (for some reason). Fix this by calling fclose() on the fmacros FILE* *after* we are done with fmacros, and then finally call g_unlink() on the temp .h file. https://bugzilla.gnome.org/show_bug.cgi?id=781525
* Fix 'Bad file descriptor' error when checking libtool versionSam Thursfield2017-04-151-1/+1
| | | | | | | | | | | | Running g-ir-scanner on Fedora 25 (libtool 2.4.6) produces the following message on stderr, twice: /usr/bin/libtool: line 2460: printf: write error: Bad file descriptor This is because we were redirecting stdout to /dev/null incorrectly -- we were opening /dev/null for reading rather than for writing. https://bugzilla.gnome.org/show_bug.cgi?id=781312
* 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-212-7/+6
| | | | | | | | | | | | | | 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
* typedefs: fix type information.Mathieu Duponchelle2017-03-142-7/+2
| | | | | | | | | | | We now reuse _create_type_from_base instead of reimplementing it in a semi-broken way in transformer, and use complete_ctype when writing it out if available. This incidentally allows us to remove a test where the comment acknowledged the non-optimal behaviour. https://bugzilla.gnome.org/show_bug.cgi?id=779959
* scanner: Add a way to specify extra libraries to link againstThibault Saunier2016-12-103-3/+7
| | | | | | | | | | | | 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
* ast: Avoid a crash with anonymous structsScott D Phillips2016-05-081-1/+2
| | | | | | | We enabled anonymous unions earlier, this is a bugfix to enable anonymous structs. https://bugzilla.gnome.org/show_bug.cgi?id=766011
* ccompiler.py: MSVC builds: Fix running on Python 3.xChun-wei Fan2016-03-171-1/+1
| | | | | When resolving libraries, open the temp file generated by dumpbin with 'r' mode rather than 'rb', since this is a text file.
* ccompiler.py: Win32: Use tempfile for resolving libsChun-wei Fan2016-03-161-21/+36
| | | | | | | | | | | | When using the NMake Makefile within the Visual Studio projects, as we are using dumpbin to resolve the .lib file that we link to, the outputs of dumpbin is captured by the Visual Studio output panel, which causes it not to be processed by proc.communicate(). This is due to dumpbin being an integrated component of Visual Studio. In order to remedy this, we need to use a temp file, and use the /out:<tempfile> flag, and look for the DLL that is linked to by the .lib that we pass in. https://bugzilla.gnome.org/show_bug.cgi?id=763739
* Do not segfault on comments with invalid UTF-8Pascal Terjan2016-03-071-0/+6
|
* giscanner/msvccompiler.py: Fix exception handlingChun-wei Fan2016-02-191-1/+1
| | | | | | | | | | Fix the syntax where we handle the exception during preprocessing, so that we won't trigger a NameError when preprocessing fails, and so the error would become clearer to people. Reported by Cosimo Lupo. https://bugzilla.gnome.org/show_bug.cgi?id=757126
* scanner: Assume gcc use the same path separator as pythonNicola Fontana2016-02-161-1/+1
| | | | | | | resolve_windows_libs() uses `gcc -print-search-dirs`. When we are cross compiling with MinGW on linux, gcc uses ':' as path separator, not ';'. https://bugzilla.gnome.org/show_bug.cgi?id=761981
* Allow overriding of dlltool nameNicola Fontana2016-02-161-2/+1
| | | | | | | | Allow to override it with the DLLTOOL environment variable, leaving "dlltool" as a fallback when not defined so backward compatibility is ensured. https://bugzilla.gnome.org/show_bug.cgi?id=761984
* scanner: Remove leading $SHELL in libtool callNicola Fontana2016-02-161-1/+2
| | | | | | | | | | | | Avoid crashes due to double shell in subprocess.Popen() on linux, e.g.: ``` >>> import subprocess >>> subprocess.Popen(['/bin/sh', '/bin/sh']) /bin/sh: /bin/sh: cannot execute binary file ``` https://bugzilla.gnome.org/show_bug.cgi?id=761982
* Use a launcher for executing g-ir-scannerNicola Fontana2016-02-161-0/+6
| | | | | | | | In cross-compilation the build system is unable to execute the compiled binary. Give the possibility to use a launcher, e.g. wine for MinGW or qemu for different CPU type. https://bugzilla.gnome.org/show_bug.cgi?id=696773
* Revert "giscanner: Disable warnings arising from -D_FORTIFY_SOURCE -O0"Philip Withnall2016-02-061-6/+0
| | | | | | | | | This reverts commit 0ff7ca94a608663649defc72021062de098853a8. As reported by Ting-Wei Lan, this breaks builds with Clang, which doesn’t support -Wno-cpp. https://bugzilla.gnome.org/show_bug.cgi?id=757934#c5
* giscanner: Disable warnings arising from -D_FORTIFY_SOURCE -O0Philip Withnall2016-01-301-0/+6
| | | | | | | | | | | | | | | Using distutils.ccompiler means that we are forced to use the CFLAGS from the system’s Python installation, which may contain -D_FORTIFY_SOURCE. The user’s environment-provided CFLAGS may contain -O0 (because they are a developer). These two flags cause a warning when used together. Silence that warning by passing -Wno-cpp to disable warnings from #warning preprocessor statements in the generated C code. It doesn’t seem to be possible to selectively undefine _FORTIFY_SOURCE or to stop using the compiler flags from distutils.sysconfig, unfortunately. https://bugzilla.gnome.org/show_bug.cgi?id=757934
* giscanner: fix tests with python3.5Marc-Antoine Perennou2016-01-181-1/+2
| | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=760682 Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
* MingGW Builds: Don't load msvcrt for MinGW64Alexey Pavlov2016-01-131-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=733535
* Win32: Fix giscannermodule.c for Python 3.5+Chun-wei Fan2016-01-081-7/+14
| | | | | | | | | | | | Python 3.5+ is now built with Visual Studio 2015, which now has a refactored set of CRT DLLs where CRT functions are placed in, so we need to acquire the _get_osfhandle() from the correct CRT DLL so that we can pass around file descriptors correctly between different CRT versions. This patch will enable Windows builds of introspection files using Python 3.5+ to work correctly. https://bugzilla.gnome.org/show_bug.cgi?id=759531
* scanner: fix line number countingDieter Verfaillie2015-12-271-13/+13
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=752047
View Lorry Controller Status