It fails to generate gst-validate-enum-types.h and gst-validate-enum-types.c
when build out of source tree. Add the path for template files.
https://bugzilla.gnome.org/show_bug.cgi?id=795531
Signed-off-by: Kai Kang <kai.kang@windriver.com>
They are mmap'ed and it gets wrong if the file is changed.
There is high probablility the user will generate new logs while
inspecting some logs in the same file
This patch fixes this runtime warning:
GstDebugViewer/Common/Data.py:67: Warning: Source ID 17 was not found when attempting to remove it
GObject.source_remove(self.source_id)
Instead of the test index in the list of tests as it is
meaningless to the user and feels weird.
Also minor fix in the test name display when running with --forever.
Make our stdout output simpler to follow by:
- Not printing the tests we launch (it is not really useful in the end)
- Using `\r` when printing the passed tests
- Not reprinting all the test in a now useless summary
The testuite version should be 'master' during development
and the version number on releases, during the pre-release
cycle, there is no nano version, thus our detection handling
was mistaking.
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
add_global_arguments() can't be used in subprojects. It's
entirely possible that devtools is a subproject but gstreamer
is picked up from an installed location, so we should
really use add_project_arguments() in both cases.
In file included from ../subprojects/gst-devtools/validate/tools/gst-validate-rtsp-server.c:21:0:
.../gst/gst.h:31:10: fatal error: gst/gstenumtypes.h: No such file or directory
This was keeping around 500-700kB of data for each test, which was
gradually raising memory usage of a full run by 100MB+
The reports are definitely not needed, and we only need to keep
information from the subprocess env variable that we might need
later on for final reporting
The xml-based MediaDescriptor were keeping open the XML file and the
associated ElementTree structures, resulting in memory usage of several
hundred megabytes.
Instead cache the information we need immediately and release the
XML structure
