| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
The gen-resources.py script must be aware of the location of
glib-compile-resources, in case it's not in the PATH.
|
| |
|
|
|
|
|
|
| |
If glib-compile-resources did not produce anything on stdout,
gen-resources.py reports success, even if it actually failed. This
can lead to a build error down the line.
Instead, just use os.execvpe after setting up the environment.
|
| |
|
|
|
|
|
| |
We should not rely on the installation prefix being part of PATH, but is
the location of the binary used by the build system.
Fixes: #126
|
| |
|
|
|
|
|
|
|
|
| |
Visual Studio builds do not assume the presence of a shell script
interpreter but would normally use cmd.exe, which would make the post
install shell script useless in such situations.
Fix this by adding a Windows .bat port of the post install script, to be
used on Visual Studio builds, which may be usable on MinGW builds if
MinGW builds can be done directly in cmd.exe.
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=795705
|
| |
|
|
|
|
|
| |
If we're installing gdk-pixbuf ourselves, we should generate the loaders
cache file — unless DESTDIR is set or we're cross-compiling, in which
case we assume that there's a packaging system hook in place to do this
at the end of a full build.
|
| |
|
|
|
|
|
|
|
|
|
| |
We need to prepend the PATH envvar so that the main GDK-Pixbuf DLL that
we just built can be loaded on Windows when running this script, as
Windows do not support rpath.
Since gdk-pixbuf-pixdata resides in the same path as the main GDK-Pixbuf
DLL, we can just use its path so that we can acquire the needed path to it.
https://bugzilla.gnome.org/show_bug.cgi?id=785767
|
|
|
This makes it easier to find them and reference them.
|
