In hotssh I use nonrecursive make. gnome-continuous uses srcdir !=
builddir by default. @GSETTINGS_RULES@ will then attempt to touch a
nonexistent path.
This patch fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=712171
GMappedFile is current unintrospectable, because it's not a registered
box type. It already has reference counting functions, so there's
little reason not to box it.
This commit adds GMappedFile to the hoard of other boxes types handled
by gboxed.c
https://bugzilla.gnome.org/show_bug.cgi?id=712393
It makes sense to match on GenericName in case an application does
not provide any keywords, but the Keywords field has been added
to explicitly support the search case, while GenericName was used
to be displayed in menus, so it makes more sense to consider
Keywords more (or equally) relevant for search.
https://bugzilla.gnome.org/show_bug.cgi?id=711640
Just copy the schemas to the builddir and compile them in place instead
of trying to mess around with creating the compiled file in a different
dir. This solves issues in the summary/description testcase when
GSettings expects the usual situation of having the .xml files present
in the same directory.
Skip the tests on inf/nan strings for the gvariant and strfuncs tests, and
skip the hex strings for the strtod tests in strfuncs as they are C99
features that are not yet supported by Visual C++ (even 2013). Use a
definition for NAN and INFINITY (that is also used in PyGObject) as
atof("NaN") and atof("Infinity") simply returns 0.0 (which is not a NAN)
in Visual C++ to fix the tests running there.
Also adapt to the format of g_ascii_formatd() when dealing with 1e99.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Use a Windows-style .bat script for the test_spawn_script() test, at least
when the code is built with Visual C++ (due to differences in how scripts
are written for shells and Windows cmd.exe), and account for Windows-style
line endings for that test too.
Let the MinGW builds (which are normally done in an MSYS BASH-style shell) continue to use the
*NIX-style script for that test.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
We need to check for the correct line endings on Windows (\r\n) for the
echo tests and currently need to skip the test_echo_eof test there, as
it depends on the cat utility that is not normally found on Windows, and
using an external installation of cat via MSYS or Cygwin would render the
test program to hang as cat waits for user input.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Remove the parts about storing up the fd's in a data structure, but call
close() on the fd's. However, retain the _get_osfhandle() check on the
fd's when we iterate through the fd's as on fd values in the iteration may
well be invalid fd's. As a result, the invalid parameter handler is still
needed for newer Microsoft CRTs (8.0/2005+) for _get_osfhandle() to
make sure that the program does not abort when we check the validity of
fd's to be closed in the loop[1].
[1]: http://msdn.microsoft.com/en-us/library/ks2530z6%28v=vs.80%29.aspx
...and only include unistd.h when we are on *NIX.
Newer Visual C++ runtimes (8.0/2005 and later) will cause the program to
crash with an internal abort() call when they detect instances of close()
being called on an invalid fd, such as when the fd is -1, and these should
be purged anyways.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
...Under various compilers when !G_DISABLE_CHECKS. Previously, the
messages that are logged differ depending whether GLib was built with GCC
or not. To simplify test cases, make all builds use a single output format
for g_return_if_fail(), g_return_val_if_fail(), g_return_if_reached(), and
g_return_val_if_reached(), by using the GCC-style format and replaceing
__PRETTY_FUNCTION__ with G_STRFUNC, so that it will work across various
compilers.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Various tests were depending on local_error being set by a callback
when it could never have been the case. Simplify async error detection
logic in those cases, and fix leak of GError.
https://bugzilla.gnome.org/show_bug.cgi?id=711802
