For example if we know the tests takes more time because, for example
we are tracing it, or running with very high debug log level we might
not want the test to timeout.
In the normal case the user probably wants to set break point or
anything when running an app in gdb, we should let him a chance to
do so.
In the case he is running in a loop, it probably means he want to
reproduce a crash or a race inside gdb so we should just go and
run in gdb.
We probably miss a few options to give him more control.
Knowing whether a test failed to run as its prerequisites were not
available, or whether those prerequisites were available and produced
unexpected/incorrect results, is a useful differentiation.
Add support for skipped tests by testing for exit code 77, used through
autotools/piglit/etc to denote a test which detected this and decided to
skip.
The syntax file does syntax highlighting for numbers, string literals,
comments, etc. Also maintains a list of valid function names.
The plugin does auto-indentation for Meson with two spaces by default.
TODO: explicit errors for decimal numbers (right now, it's just
unhighlighted), check kwargs, default options, etc.
I hit an issue when building gtk-doc documentation. The issue is
my fault, but the error output from Meson makes it look like an
internal error:
[0/1] 'Running external command libtracker-sparql-doc.'
Building documentation for libtracker-sparql
Traceback (most recent call last):
File "/home/sam/meson/meson.py", line 26, in <module>
sys.exit(main())
File "/home/sam/meson/meson.py", line 23, in main
return mesonmain.run(launcher, sys.argv[1:])
File "/home/sam/meson/mesonbuild/mesonmain.py", line 249, in run
sys.exit(run_script_command(args[1:]))
File "/home/sam/meson/mesonbuild/mesonmain.py", line 239, in run_script_command
return cmdfunc(cmdargs)
File "/home/sam/meson/mesonbuild/scripts/gtkdochelper.py", line 183, in run
options.ignore_headers.split('@@') if options.ignore_headers else [])
File "/home/sam/meson/mesonbuild/scripts/gtkdochelper.py", line 133, in build_gtkdoc
gtkdoc_run_check(mkhtml_cmd, os.path.join(abs_out, 'html'))
File "/home/sam/meson/mesonbuild/scripts/gtkdochelper.py", line 55, in gtkdoc_run_check
raise MesonException('\n'.join(err_msg))
mesonbuild.mesonlib.MesonException: 'gtkdoc-mkhtml' failed with status 6
warning: failed to load external entity "../overview.sgml"
../libtracker-sparql-docs.sgml:20: element include: XInclude error :
could not load ../overview.sgml, and no fallback was found
warning: failed to load external entity "../examples.sgml"
../libtracker-sparql-docs.sgml:41: element include: XInclude error :
could not load ../examples.sgml, and no fallback was found
FAILED: libtracker-sparql-doc
After this patch, the output is much clearer:
[0/1] 'Running external command libtracker-sparql-doc.'
Building documentation for libtracker-sparql
Error in gtkdoc helper script:
'gtkdoc-mkhtml' failed with status 6
warning: failed to load external entity "../overview.sgml"
../libtracker-sparql-docs.sgml:20: element include: XInclude error :
could not load ../overview.sgml, and no fallback was found
warning: failed to load external entity "../examples.sgml"
../libtracker-sparql-docs.sgml:41: element include: XInclude error :
could not load ../examples.sgml, and no fallback was found
Note the actual errors from xsltproc are swallowed by gtkdoc-mkhtml
1.25.1, they're only displayed in the example above because I made a
patch: <https://bugzilla.gnome.org/show_bug.cgi?id=774812>
The library from which we extract should have multiple sources
from which we choose a strict subset otherwise we're testing almost the
same case extracting all the objects.
This exposes a bug in how we were doing extract checking for unity
builds.
The install argument is allowed for CustomTargets, but we use
install_header as the setting now. Also, setting a generic template when
specifying the more specific source or header template shouldn't be
allowed.