| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
|
|
|
|
| |
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
|
|
|
|
| |
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
Reference: https://bugzilla.gnome.org/show_bug.cgi?id=665672
Signed-off-by: Dominique Leuenberger <dimstar@opensuse.org>
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=765618
|
|
|
|
| |
This is needed so that gtk+-3.0.pc will be complete.
|
|
|
|
|
|
|
|
|
| |
Some packages might have some parts that are built for certain build
configs, meaning that they could have .pc files of their own, such as
Pango, where PangoFT2 is optionally built. Allow such an option if
needed.
Also remove some trailing whitespaces.
|
| |
|
|
|
|
|
|
|
|
|
| |
That is, for Cairo, Freetype and libxml2, as packages that we support
for Visual Studio builds depend on these packages, specifically for
generating the introspection files for them.
These are generated with rather generic info in them, so that they are
sufficient for our purposes here.
|
|
|
|
|
|
|
| |
Allow using a envvar to specify the path to pkg-config, as it may not be
in the PATH.
Suggestion given by the HexChat project.
|
| |
|
| |
|
|
|
|
|
|
| |
We also want to include the gi-install.vcxproj.filters for the
Visual Studio 2012~2015 builds, to make the gi-install project
look nicer in the IDE, which was done in the last commit.
|
|
|
|
|
|
|
| |
Generate the .pc files as part of the build of the Visual Studio projects,
and "install" them to $(CopyDir)\lib\pkgconfig, so that it would make it
easier for packages building introspection to find the .pc files for g-i
for Visual Studio builds.
|
|
|
|
| |
This is used for generating the pkg-config file for this package.
|
| |
|
|
|
|
|
| |
The build process of the introspection files for this package has been
further improved lately, so let people know.
|
|
|
|
|
| |
When resolving libraries, open the temp file generated by dumpbin
with 'r' mode rather than 'rb', since this is a text file.
|
|
|
|
|
| |
Make my last patch to this file conform to the code style in the rest
of this file.
|
|
|
|
| |
build/win32/vs10/gi-install.propsin does need to be updated...
|
|
|
|
|
|
|
| |
build/win32/vs10/gi-install.props is generated during 'make dist', so we
don't want to add it into vresion control.
Also drop a property sheet that is no longer used.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GLib has been recently updated to optionally generate the .pc files
within the MSVC builds, which is needed to build the introspection
files, if Python is available. As we are looking for the .pc files from a
common location as a result, we can build the introspection files within
the project files, so that the build process does not have to be split
into 2 stages.
This is done by using wrapper projects that calls the NMake Makefiles that
is used to build the introspection files.
Note that although the IDE claims that the introspection
files failed to build, but they are really generated-so some investigation
is needed to see whether we can silence those false-positive errors.
Also clean up the property sheets a bit.
|
|
|
|
|
|
|
|
|
|
|
| |
Due to an MSVC 2012 x64 compiler issue, the compiler generates bad code
for bdz.c, so the for loop in assign() continues running until the point
i falls below zero, causing an access violation when we try to do
curr_edge=queue[i]; (line 427 in bdz.c). Address this issue by breaking
out of the loop at the end of it when i reaches 0 after doing the
necessary processing.
https://bugzilla.gnome.org/show_bug.cgi?id=733595
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Allow the CFG parameter to accept "Debug" and "Release", as this is the
convention of the project files of Visual Studio. Also use TOP_SRCDIR
everywhere rather than hard-coding '..\..' for it.
|
| |
|
| |
|
|
|
|
|
|
| |
This updates the replace.py script to support replacing multiple items in
a file from GLib's build/win32, which allows us to simplify the script
that is used to create cairo-1.0.gir for Visual Studio builds.
|
|
|
|
|
| |
We need to get the full, complete path for $(PREFIX) for all cases, not
just when using the default prefix.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GLib recently had a script that would generate the pkg-config files for
its Visual Studio builds, which would be sufficient for the need of
building introspection files, so update the NMake Makefile modules to
look for them automatically, without the need to manually set
PKG_CONFIG_PATH in the console, provided that the build was done in the
same directory tree[1] and was not moved. Note that this would precede
any PKG_CONFIG_PATH's that were already set in the console.
[1]: This would mean:
$(tree_root)
|
|--$(GLib_src_tree)
|--$(G-I_src_tree)
|...
|
| |
|
|
|
|
|
|
|
|
| |
...for generating GLib-2.0.gir, this is to ensure that the headers in
include/gio-win32-2.0 is also included when we generate the .gir files, as
gio.h will include the include/gio-win32-2.0 headers at some point. This
will ensure that all the .gir's that depend on GLib-2.0.gir will make the
necessary inclusions.
|
|
|
|
|
|
| |
We want to make sure that the include/gio-win32-2.0 is also being searched
for the headers for GIO as well, and the GLib include paths should first
be searched before the include paths of its dependencies.
|
|
|
|
|
|
|
|
|
| |
These were leaking memory when dumping introspection data from projects
for building their GIR files. That’s generally not a problem, unless
you’re trying to build the project with -fsanitize=address, which causes
the GIR build phase to error out due to leaking memory.
https://bugzilla.gnome.org/show_bug.cgi?id=762653
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
While cross-compiling, "$PKG_CONFIG" is not "pkg-config", so do not
assume it when calling g-ir-scanner to build up the base gir files.
https://bugzilla.gnome.org/show_bug.cgi?id=761983
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 is false on x32, arm32 on Linux and on 32-bit archs of FreeBSD,
OpenBSD.
In general we've been moving g-i away from supporting time_t due to
various problems - GLib-using apps should use GTimeVal or GDateTime
etc.
https://bugzilla.gnome.org/show_bug.cgi?id=736109
|
|
|
|
|
|
|
|
| |
This is a regression test for marshalling callback arguments from signals
with an array parameter and separate length parameter into closures in
the introspected language.
https://bugzilla.gnome.org/show_bug.cgi?id=761659
|
| |
|
|
|
|
|
|
|
| |
This is a regression test for returning out arrays of structs, like
gdk_keymap_get_entries_for_keyval() for example.
https://bugzilla.gnome.org/show_bug.cgi?id=761658
|
|
|
|
|
|
|
|
|
| |
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
|