This code was unconditionally present in the gtester Makefile:
test-nonrecursive: ${TEST_PROGS}
On Windows, our testcases are compiled with a .exe suffix. That means
that if we had 'foo' in TEST_PROGS, running "make check" would depend on
'foo' (not foo.exe) being compiled.
We could bring the EXEEXT in here to fix that up, but gtester doesn't
work on Windows at all, so better to just disable it in that case.
The long format that displays the exact number of bytes with separators
(ie: "123,456,789 bytes") uses the ' format modifier, which is
unsupported on Windows. Disable that for now, until we come up with a
better solution.
We need to test the case of eventfd in the libc but no kernel support.
In order to do that, we add a separate compile of the GWakeup testcase
that interposes an 'eventfd' symbol that always returns -1 with errno
set. That will trigger the fallback case.
GWakeup is a utility class to handle the cross-thread signalling needs
of GMainContext and GCancellable. It may find some other users as well.
The desire here is to properly hide the implementation details in a
module which can be properly unit tested and used in GMainContext and
GCancellable without a rats nest of #ifdef.
Fix some bugs in the fallback case of g_unix_open_pipe:
- close both halves of the pipe on error (not just one)
- set the cloexec flag on both halves of the pipe (instead of settings
it twice on one half)
socket->priv->connected was only being set if g_socket_connect()
succeeded right away; in the case where it returns G_IO_ERROR_PENDING,
it never got set. Fix that by having g_socket_check_connect_result()
set it on success.
Otherwise, we may run into trouble as opening a peer-to-peer
connection uses a socket client, which uses a proxy resolver
which may end up using gsettings, whose dconf backend may end
up using the session bus to talk to dconfd...
Per IRC discussion, we can just ask bindings to use
g_key_file_get_value() to test for the existence of a key.
I left the "fixed" code in the source tree as static because it makes
more sense to me.
If gtk-doc sees 'Returns ...' written in the text of the documentation
for a macro, it thinks that you are talking about the return value.
Avoid doing that and use 'Returns:' explicitly if we mean to.
