Upstream seems to have stopped doing releases, but we need to update for better
Windows and Visual Studio support.
This patch only updates the libcheck sources and ignores the compatibility
sources for now.
https://bugzilla.gnome.org/show_bug.cgi?id=775870
Hurd also defines __MACH__, but it does not have mach_absolute_time. Use
the more strict __APPLE__ instead.
Has also been sent upstream: https://github.com/libcheck/check/pull/65
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Mathieu Duponchelle <mathieu.duponchelle@opencreed.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
POSIX standards requires strsignal() to return a pointer to a char,
not a const pointer to a char. [1] On uClibc, and possibly other
libc's, that do not HAVE_DECL_STRSIGNAL, libcompat.h declares
const char *strsignal (int sig) which causes a type error.
[1] man 3 strsignal
https://bugzilla.gnome.org/show_bug.cgi?id=763567
To allow the GstTestClock to be used as a GstSystemClock, it is
useful to implement the clock-type property that GstSystemClock
provides. This allows GstTestClock to be used as the system clock
with code that expects a GstSystemClock.
https://bugzilla.gnome.org/show_bug.cgi?id=762147
POSIX standards requires strsignal() to return a pointer to a char,
not a const pointer to a char. [1] On uClibc, and possibly other
libc's, that do not HAVE_DECL_STRSIGNAL, libcompat.h declares
const char *strsignal (int sig) which causes a type error.
[1] man 3 strsignal
https://bugzilla.gnome.org/show_bug.cgi?id=763567
Similar to the stress test functions for buffers that has a callback to
create the buffer to be pushed, it's useful to have functions that use a
callback to create the event to be pushed.
API: gst_harness_stress_push_event_with_cb_start()
API: gst_harness_stress_push_event_with_cb_start_full()
API: gst_harness_stress_send_upstream_event_with_cb_start()
API: gst_harness_stress_push_upstream_event_with_cb_start_full()
https://bugzilla.gnome.org/show_bug.cgi?id=761932
Depending on when gst_harness_pull was called - before the buffer reached
gst_harness_chain or after we can get different behaviors of the test
with enabled blocking push mode. The fix makes the behavior always the
same. In pull function we get the buffer first, thus making sure
gst_harness_chain waits for the signal, and emitting the signal after.
https://bugzilla.gnome.org/show_bug.cgi?id=761931
Set the sink_forward_pad to NULL before tearing down sink_harness to
avoid that the harness tries to forward events/queries to it while it's
tearing down.
https://bugzilla.gnome.org/show_bug.cgi?id=761904
Broke this when I removed the G_GNUC_PRINTF in a previous
commit to fix indentation, since it was not really needed.
Turns out unlike gcc clang warns though if a non-literal
format string is passed then. Fix indentation differently.
http://clang.llvm.org/docs/AttributeReference.html#format-gnu-format
In order for gst_harness_new_full to be MT-safe the increase and
decrease of HARNESS_REF must be MT-safe. This allows for creating
multiple harnesses from different threads wrapping the same element.
https://bugzilla.gnome.org/show_bug.cgi?id=754661
1. Get a list of pad templates from the element class, not the
factory. This allows us to interact with test-elements that does
not have a factory.
2. Use the pad_template_caps in caps-queries when caps is not set
explicitly on the pad. Not doing so is simply wrong, and prohibits
interactions with special templates used for testing.
https://bugzilla.gnome.org/show_bug.cgi?id=754193
To be able to disable the slightly "magic" forwarding of the
necessary events between the harnesses.
Also introduce a new test-suite for GstHarness, that documents the
feature, and should hopefully expand into documenting most of the
features the harness possesses.
https://bugzilla.gnome.org/show_bug.cgi?id=752746
Even though asserts can't be disabled in GstHarness, Coverity still
complains about running code inside them. Moving the code to outside the
g_asserts().
CID #1311326, #1311327, #1311328
By introducing gst_harness_add_src_harness and gst_harness_add_sink_harness
we collect all sub-harness setup in one function, making the previous
sub-harness creation functions now calls these directly, and making it
much easier (and less error-prone) to add your own src or sink-harness
using the more generic harness-creation functions.
The element flag does not indicate wether a bin should be tested as a
source or as a sink, eg. a bin with the sink flag may still have a
source pad and a bin with the source flag may have a sink pad. In this
case it is better to determine the element type by looking at the
available pads and pad templates.
Also rename srcpad and sinkpad where it actually represents
element_srcpad_name and element_sinkpad_name.
https://bugzilla.gnome.org/show_bug.cgi?id=752493
check_run.c: In function 'sig_handler':
check_run.c:127:13: warning: 'child_sig' may be used uninitialized in this function [-Wmaybe-uninitialized]
killpg(group_pid, child_sig);
^
check_run.c:130:31: warning: 'idx' may be used uninitialized in this function [-Wmaybe-uninitialized]
sigaction(sig_nr, &old_action[idx], NULL);
^
Otherwise e.g. ctrl+c in the test runner exits the test runner, while the test
itself is still running in the background, uses CPU and memory and potentially
never exits (e.g. if the test ran into a deadlock or infinite loop).
The reason why we have to manually kill the actual tests is that after
forking they will be moved to their own process group, and as such are
not receiving any signals sent to the test runner anymore. This is supposed
to be done to make it easier to kill a test, which it only really does if
the test itself is forking off new processes.
This fix is not complete though. SIGKILL can't be caught at all, and error
signals like SIGSEGV, SIGFPE are currently not caught. The latter will only
happen if there is a bug in the test runner itself, and as such seem less
important.
Previously GStreamer got access to the libcheck interface by including
libs/gst/check/check.h which in turn included internal-check.h in the
same directory. internal-check.h was generated by copying
libs/gst/check/libcheck/check.h which in turn was generated from
check.h.in in the same directory. In this case generating
libs/gst/check/libcheck/check.h is unnecessary, in addition this file
was accidentally distributed in generated project tarballs.
Now libs/gst/check/internal-check.h is generated directly from
libs/gst/check/libcheck/check.h.in by configure. This means that the
libcheck source must include internal-check.h instead of the previously
generated libs/gst/check/libcheck/check.h. However the unnecessary
intermediate step is now skipped.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=741359
Previously embedded libcheck versions did not depend on (u)intmax_t and
doing so would require projects using GStreamer's check framework to add
AX_CREATE_STDINT_H to their configure.ac. A workaround is to fallback to
glib types. This patch assumes that glib.h is always included before
internal-check.h which is ok since everything Gstreamer would include
gst/gstcheck.h instead of directly including internal-check.h.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=727826
Reintroduced patches:
* Make sure that fail_if(1) actually fails
from commit 9f99d056a2
New patches due to updated libcheck (based on 0.9.14):
* Checks in m4/check-checks.m4 to cater for new dependencies
* Conditional compile-time compat POSIX fallbacks for libcheck
* Avoid relative paths for libcheck header files
* Make timer_create() usage depend on posix timers, not librt
* Rely on default AX_PTHREAD behavior to allow HAVE_PTHREAD to be used
when checking for types and functions (like clock_gettime())
* Avoid double declaration of clock_gettime() when availabe outside of
librt by making compat clock_gettime() declaration conditional
* check 0.9.9 renamed _fail_unless() and 0.9.12 later renamed it again
to _ck_assert_failed(), so ASSERT_{CRITICAL,WARNING}() now calls this
function
* Remove libcheck fallback infrastructure for malloc(), realloc(),
gettimeofday() and snprintf() since either they appear to be
available or they introduce even more dependencies.
The result is an embedded check in gstreamer that has been tested by
running check tests in core, -base, -good, -bad, -ugly and rtsp-server
on Linux, OSX and Windows.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=727826
This lifts the files almost verbatim (the changes being running though
gst-indent and fixing the FSF address) from the upstream respository.
Therefore this commit reverts some GStreamer-specific patches to check
that will be reintroduced next.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=727826
TRUE is 1, but every other non-zero value is also considered true. Comparing
for equality with TRUE would only consider 1 but not the others.
Also normalize booleans in a few places.
Add a method letting people to ensure that unreffing one object
leads to its destruction, and possibly the destruction of more object
(think destruction of a GstBin etc...).
https://bugzilla.gnome.org/show_bug.cgi?id=736477
* GstGlobalDeviceMonitor was renamed to GstDeviceMonitor
* Expand GST_MESSAGE_DEVICE to the full enum value names
* Correct the incorrect references to the GstDeviceProvider interfaces
* Describe caps arguments for gstcheck interface
* Add missing docs for GstNetAddressMeta and its add function
* Add docs for toc helper macros
* Avoid refering to GstValueList type as done elsewhere
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=732786
exit() will call atexit handlers, which may try to
clean up things or wait for things to get cleaned up,
which we don't want or need. We just want to stop
and let the parent know about the failure as quickly
as possible in case fork() is used.
Fixes timeouts on assert failures in checks where
an exit handler waits for things to stop, but they
don't stop because they haven't been shut down,
and they haven't been shut down because there's no
simple way to do so on failures.
http://sourceforge.net/p/check/patches/50/
Keep it simple. Likely also makes things easier for bindings,
and efficiency clearly has not been a consideration given how
the existing code handled these lists.
In order to be deterministic, multiple waiting GstClockIDs needs to be
released at the same time, or else one can get into the situation that
the one being released first can add itself back again before the next
one waiting is released.
Test added for new API and old tests rewritten to comply.
This reverts commit b9313afc75.
This should be fixed in upstream libcheck instead. We want
to keep diff of our local copy to upstream libcheck
to a minimum.
GST_CHECKS can be simply "test*" to run run all tests (including those that are
marked broken). Update the sparse comments a bit to tell how this works.
* fix typo GstBufferFlag -> GstBufferFlags
* fix typo GstFeatures -> GstCapsFeatures
* fix typo GstAllocatorParams -> GstAllocationParams
* fix typo GstContrlSources -> GstControlSource
* do not refer to gstcheck as an object
* make references gtk_init() and tcase_set_timeout() not be references
* gst_element_get_pad() renamed gst_element_get_static_pad()
* gst_clock_id_wait_async_full() renamed gst_clock_id_wait_async()
* _drop_element() is really gst_queue_array_drop_element()
* gst_pad_accept_caps() was removed, do not refer to it
* separate GST_META_TAG_MEMORY_STR declaration from description
* do not describe removed gst_collect_pads_collect()
* correctly link to GstElementClass' virtual set_context()
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=719614
