We're testing for particular error messages, so we need to set to a C
locale to make sure we get the untranslated version.
Previously, this test set the LANG environment variable, but that's not
good enough if LANGUAGE is also set. The only way to ensure that
LANGUAGE is ignored is to disable l10n with LC_ALL=C.
Allow passing a NULL domain to g_test_expect_message(), and more
importantly, don't crash if a message with a NULL domain gets logged
while there is an expected message.
Convert {glib,gobject,gio}/tests to use the automake TAP driver
and test harness instead of gtester. To do so, we add a glib-tap.mk
that provides the same interface as glib.mk, except for the
reporting and coverage testing functionality. Eventually, we may
want to replace glib.mk with it. I've not yet converted the
toplevel tests/ directory, since it mixes gtestutils tests with
other binaries.
https://bugzilla.gnome.org/show_bug.cgi?id=692125
This line was apparently causing build problems on Win64,
and since the only test involving the t_str variable was
already commented out, lets just take this out altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=696970
The documentation for this function explicitly gives valid
ranges for the arguments and states that out-of-range arguments
will cause NULL to be returned. Only, the code didn't check
the ranges, and crashed instead. Fix that and add a testcase
for invalid arguments. It turns out that the test_z testcase
was providing invalid arguments and relied on g_date_time_new
to return a non-NULL value anyway, so this commit fixes that
testcase as well.
https://bugzilla.gnome.org/show_bug.cgi?id=702674
test_GDateTime_diff() checks that the span from 2009-01-01 to
2010-01-01 is exactly 365 * G_TIME_SPAN_DAY, but it does this using
local time, and so fails if you are in a timezone that is in the
southern hemisphere which only did DST during one of 2008-2009 and
2009-2010 (in which case the year will end up being one hour too long
or too short).
Switch the diff tests to use UTC time instead; there are plenty of
other local time tests already.
https://bugzilla.gnome.org/show_bug.cgi?id=701529
The timeout-based tests could fail on slow or heavily-loaded machines.
Change them to use a counter-based "timeout" source rather than a
time-based one, so they no longer depend on wall time.
https://bugzilla.gnome.org/show_bug.cgi?id=700460
On a heavily loaded system, it's possible that both our normal
condition *and* the timeout occurred. In that case we can just ignore
the timeout.
While I did add a "sig_timeout" boolean, we don't need to add any
assertions around whether or not it was reached - the assertions
covering the non-timeout case are sufficient. The sig_timeout boolean
is mainly for later debugging.
https://bugzilla.gnome.org/show_bug.cgi?id=700460
If someone creates a unix signal source for e.g. SIGINT, and then
removes it, reset the handler to SIG_DFL.
Not doing this was the source of race conditions in the
glib/tests/unix test, but this will also just make us a "good citizen"
by cleaning up.
For example, if a project temporarily creates a handler for SIGTERM,
and then later removes it, they almost certainly want SIGTERM to
revert to the default of terminating the process, rather than doing
nothing.
https://bugzilla.gnome.org/show_bug.cgi?id=704699
We can't reset the pending flag for a signal until we've traversed
the whole list, as the documentation clearly says that in case multiple
sources they all get invoked.
This is still racy if you get a signal after checking the flag
but before resetting it, but it was the same before. The correct
fix would be to use sigwait() or signalfd(), but that would mean
blocking all signals in all threads, which is not compatible
with existing applications.
https://bugzilla.gnome.org/show_bug.cgi?id=704322
As the comment says, we may be delayed an arbitrary amount of time on
non-idle systems; update the assertions to reflect this.
This should fix periodic failures in the gnome-ostree continuous
integration system.
https://bugzilla.gnome.org/700460
Perform a substantial cleanup of the build system with respect to
building and installing testcases.
First, Makefile.decl has been renamed glib.mk and substantially
expanded. We intend to add more stuff here in the future, like canned
rules for mkenums, marshallers, resources, etc.
By default, tests are no longer compiled as part of 'make'. They will
be built when 'make check' is run. The old behaviour can be obtained
with --enable-always-build-tests.
--disable-modular-tests is gone (because tests are no longer built by
default). There is no longer any way to cause 'make check' to be a
no-op, but that's not very useful anyway.
A new glibtests.m4 file is introduced. Along with glib.mk, this
provides for consistent handling of --enable-installed-tests and
--enable-always-build-tests (mentioned above).
Port our various test-installing Makefiles to the new framework.
This patch substantially improves the situation in the toplevel tests/
directory. Things are now somewhat under control there. There were
some tests being built that weren't even being run and we run those now.
The long-running GObject performance tests in this directory have been
removed from 'make check' because they take too long.
As an experiment, 'make check' now runs the testcases on win32 builds,
by default. We can't run them under gtester (since it uses a pipe to
communicate with the subprocess) so just toss them in TESTS. Most of
them are passing on win32.
Things are not quite done here, but this patch is already a substantial
improvement. More to come.
This should be the last users that need to be ported.
For some of the oldschool non-gtester-ified tests, we call g_test_init()
from main() because it is necessary in order to use
g_test_build_filename().
Since this feature is so utterly automake-centric, we may as well be
using the same terminology as automake itself (ie: although it's
BUILT_SOURCES, it's DIST_EXTRA, not DISTED).
Also add some comments to the enum explaining that these terms are
really corresponding directly to the automake terms.
https://bugzilla.gnome.org/show_bug.cgi?id=549783
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
See https://live.gnome.org/GnomeGoals/InstalledTests for more
information.
The tests now support being run both uninstalled and installed, so
'make check' works for those who want it. For tests which need data
files, the way this works is they look in the compiled in value of
SRCDIR by default, and the generated tests use "env G_TEST_DATA=" to
override that.
This patch only converts glib/tests for now; if this patch looks good,
I'll do the rest of the tests.
https://bugzilla.gnome.org/show_bug.cgi?id=699079
Rather than overloading --verbose, just skip the tests that aren't
supposed to be run in the parent process (so that if you do run the
toplevel test with --verbose, it doesn't immediately error out).
https://bugzilla.gnome.org/show_bug.cgi?id=679683
g_test_trap_fork() doesn't work on Windows and is potentially flaky on
unix anyway given the fork-but-don't-exec. Replace it with
g_test_trap_subprocess(), which re-spawns the same program with
arguments telling it to run a specific (otherwise-ignored) test case.
Make the existing g_test_trap_fork() unit tests be unix-only (they
never passed on Windows anyway), and add a parallel set of
g_test_trap_subprocess() tests.
Also fix the logic of gtestutils's "-p" argument (which is used by the
subprocess tests); previously if you had tests "/foo/bar" and
"/foo/bar/baz", and ran the test program with "-p /foo/bar/baz", it
would run "/foo/bar" too. Fix that and add tests.
https://bugzilla.gnome.org/show_bug.cgi?id=679683
