| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Also free memory associated with macro name when it is unused.
|
|
|
|
|
|
|
|
| |
Macro constants may now refer to constants defined in source files.
Test case provided by Philip Chimento.
Fixes issues #173 and #75.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
_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
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
These qualifiers are present in header files on macOS (introduced in
XCode 7).
https://bugzilla.gnome.org/show_bug.cgi?id=784458
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
We enabled anonymous unions earlier, this is a bugfix to enable
anonymous structs.
https://bugzilla.gnome.org/show_bug.cgi?id=766011
|
|
|
|
|
| |
When resolving libraries, open the temp file generated by dumpbin
with 'r' mode rather than 'rb', since this is a text file.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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 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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=760682
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=733535
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=752047
|
|
|
|
|
|
|
|
|
|
|
|
| |
On bug #719966, the question arose of whether parameters annotated with
(element-type) but not (not nullable) are regarded as nullable or
non-nullable.
Add some new unit tests to Regress-1.0.gir to check the behaviour is as
expected: annotating a parameter with (element-type) implicitly makes it
non-nullable (unless also annotated with (nullable)).
https://bugzilla.gnome.org/show_bug.cgi?id=757678
|
|
|
|
|
|
|
|
| |
If the file is new, set the permissions to 0644.
If the file with the name specified as --output exists, copy its
metadata onto the temporary output file.
https://bugzilla.gnome.org/show_bug.cgi?id=757442
|
|
|
|
|
|
|
| |
If the move resulted in EPERM, discard the temporary output file, but
raise the error so that the tool exits with a nonzero status.
https://bugzilla.gnome.org/show_bug.cgi?id=757442
|
|
|
|
|
|
|
| |
We need to encode the identifier-filter command to bytes, and decode its
outputs to ascii in order for it to work on Python 3.x.
https://bugzilla.gnome.org/show_bug.cgi?id=757126
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Windows builds check the library that was passed into the introspection
scanner to deduce the correct DLL that is to be used by the .gir/.typelib
file, but this was not updated for Python 2.x/3.x compatibility, as the
outputs of a subprocess must be decoded. Fix this for both MSVC and
MinGW-based builds.
https://bugzilla.gnome.org/show_bug.cgi?id=757126
|
|
|
|
|
|
| |
This is checked for Python 2.7.x compatibility as well.
https://bugzilla.gnome.org/show_bug.cgi?id=757126
|
|
|
|
|
|
|
|
|
| |
Darwin's linker doesn't like "-rpath=path"; instead pass "-rpath path",
which works on more linkers than the version with the = sign does.
Additionally, Darwin's linker has no equivalent for "--no-as-needed" (it
seems to do the right thing by default?)
https://bugzilla.gnome.org/show_bug.cgi?id=625195
|
|
|
|
|
|
|
|
|
|
| |
g-ir-scanner now supports something like this:
typedef void my_callback(int);
Notice how my_callback is not a pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=755645
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
They're just internal bits for users of C, shouldn't be part of the
API.
https://bugzilla.gnome.org/show_bug.cgi?id=755882
|
|
|
|
|
|
|
| |
The nullable code needs to search via index lookup of closure_name,
which drops the need to (incorrectly) assign closure_name again.
https://bugzilla.gnome.org/show_bug.cgi?id=756352
|