We don't need to run binaries we just built in order to successfully
build GLib and friends any more.
Since commit b74e2a7, we don't need to run glib-genmarshal when building
GIO; since commit f9eb9eed, all our tests (including the ones that do
need to run binaries we just built) are only built when running "make
check", instead of unconditionally at every build.
This means that we don't need to check for existing, native binaries
when cross-compiling, and fail the configuration step if they are not
found — which also means that you don't need to natively build GLib for
your toolchain, in order to cross-compile GLib.
We can also use the cross-compilation conditional, and skip those tests
that require a binary we just built in order to build.
https://bugzilla.gnome.org/show_bug.cgi?id=753745
I searched all files that mention g_test_run, and replaced most
g_print() calls. This avoids interfering with TAP. Exceptions:
* gio/tests/network-monitor: a manual mode that is run by
"./network-monitor --watch" is unaffected
* glib/gtester.c: not a test
* glib/gtestutils.c: not a test
* glib/tests/logging.c: specifically exercising g_print()
* glib/tests/markup-parse.c: a manual mode that is run by
"./markup-parse --cdata-as-text" is unaffected
* glib/tests/testing.c: specifically exercising capture of stdout
in subprocesses
* glib/tests/utils.c: captures a subprocess's stdout
* glib/tests/testglib.c: exercises an assertion failure in g_print()
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The test is to remove all the odd values with my_hash_callback_remove(),
then iterate over all values and verify that they are even. However,
failing this check would just print "bad!" instead of failing the test.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
gdb is run in batch mode, and can leave leave the program being
executed/debugged running when the batchfile is finished. Explicitly
"quit"ing the subprocess prevents it from leaving the stray subprocess
when gdb finishes.
https://bugzilla.gnome.org/show_bug.cgi?id=731366
It turns out that due to a recent gdm change, the inherited
signal mask has SIGUSR1 blocked - which is bad news for
tests using SIGUSR1. Fix the test by explicitly checking the
signal mask before using SIGUSR1.
The mapping-test is failing under gnome-continuous. I suspect this
is simply due to running many tests in parallel, and mapping-test
being racy. Replace the blind sleep by signals, to avoid the
races.
g_time_val_from_iso8601 was attempting to parse strings
having only a date, but failed to actually set the timeval
despite returning TRUE. Since the docs state that the function
only parses strings containing a date and a time, just return
FALSE in this case.
Also remove an incomplete testcase for this behaviour that was
just checking the boolean return value, but not timeval.
In Windows development environments that have it, <unistd.h> is mostly
just a wrapper around several other native headers (in particular,
<io.h>, which contains read(), close(), etc, and <process.h>, which
contains getpid()). But given that some Windows dev environments don't
have <unistd.h>, everything that uses those functions on Windows
already needed to include the correct Windows header as well, and so
there is never any point to including <unistd.h> on Windows.
Also, remove some <unistd.h> includes (and a few others) that were
unnecessary even on unix.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
...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
Visual C++ does not like function declarations being different from
their prototypes, so make the prototypes match the declarations by
decorating them with G_MODULE_EXPORT.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Recent changes to the properties testcase made invalid use of the GArray
free function. This free function takes a pointer to the item to be
freed, not the item itself. Since that item was a pointer to a GObject,
g_object_unref() was getting a GObject**, rather than a GObject*.
The use of GArray in this testcase is pretty questionable in the first
place, so just use C arrays instead.
This commit adds a test to ensure that during a signal emission, if
a signal handler gets disconnected, it won't be run, even if it would
have run before the disconnection.
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.
After this patch, there is but one remaining use of g_thread_init(),
which is in tests/slice-threadinit.c, a testcase dedicated to testing
the functionality of gslice across a g_thread_init() boundary.
This testcase is pretty meaningless these days... probably we should
delete it.
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().
testgobject.c and timeloop-closure.c are the only two tests in the
toplevel tests/ directory that depend on gobject, so move them to
tests/gobject/ along with the other gobject tests.
Both of these were in noinst_PROGRAMS and not TESTS, so keep them that
way when we move them.
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
We have some testcases that assert that type modules are unloaded after
the last reference on them is dropped. Comment out those asserts now
that we turned the last unref into a no-op.
https://bugzilla.gnome.org/show_bug.cgi?id=693351
We only want to control the default visibility for our five main
installable libraries: libglib, libgthread, libgmodule, libgobject,
libgio. We should therefore only set -fvisibility=hidden when building
those.
Use a separate substitution variable for this purpose.
Using CFLAGS directly leads to some modules built in testcases not
exporting their symbols (and then the tests fail). It also affects the
fam file monitoring module.
Colin had originally done it this way in his visibility patch series but
I failed to understand why so I didn't copy it. Now I do.
Also: revert changes made to two testcases in an attempt to work around
this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=691756
Add a check to prevent adding an interface to a class that has already
had its class_init done.
This is an incompatible change but it is suspected that there are not
many users of this functionality. Two known exceptions are pygobject
(fixed in bug 686149) and our own testsuite (affected tests have been
temporarily disabled by this patch).
Once we confirm that nobody else is using this functionality we can
remove a rather large amount of code for dealing with this case.
https://bugzilla.gnome.org/show_bug.cgi?id=687659
1) use "../libtool" rather than "libtool" to avoid problems
with wacky OS X not-actually-libtool
2) Use libtool on the libtool script, not the binary, so that it
actually does anything
3) Don't use "gdb --ex" since it's apparently new-ish/non-portable.
https://bugzilla.gnome.org/show_bug.cgi?id=684723
Add a check to prevent adding an interface to a class that has already
had its class_init done.
This is an incompatible change but it is suspected that there are not
many users of this functionality. Two known exceptions are pygobject
(fixed in bug 686149) and our own testsuite (affected tests have been
temporarily disabled by this patch).
Once we confirm that nobody else is using this functionality we can
remove a rather large amount of code for dealing with this case.
https://bugzilla.gnome.org/show_bug.cgi?id=687659
Add a check to prevent adding an interface to a class that has already
had its class_init done.
This is an incompatible change but it is suspected that there are not
many users of this functionality. Two known exceptions are pygobject
(fixed in bug 686149) and our own testsuite (affected tests have been
temporarily disabled by this patch).
Once we confirm that nobody else is using this functionality we can
remove a rather large amount of code for dealing with this case.
https://bugzilla.gnome.org/show_bug.cgi?id=687659
I'm normally a big fan of small atomic commits, but I also want to get
things done this afternoon...
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687441
Reviewed-by: Colin Walters <walters@verbum.org>
Very many testcases, some GLib tools (resource compiler, etc) and
GApplication were calling g_type_init().
Remove those uses, as they are no longer required.
https://bugzilla.gnome.org/show_bug.cgi?id=686161
