* Fix clang-tidy return value reporting
In case clang-tidy is invoked manually, i.e. if run-clang-tidy(.py) is
not found, Meson would not report the return value. This is caused by
ignoring the return value of manual_clangformat() in clangformat()
within mesonbuild/scripts/clangtidy.py.
Even though only more recent-versions of clang-tidy actually report an
non-zero exit code if errors are found, there is no reason Meson
shouldn't simply report any error codes it received from clang-tidy.
Fixes#7948.
* Rename methods in clangtidy.py from clangformat to clangtidy
For some unknown reason, the method names in clangtidy.py are clangformat()
and manual_clangformat(). This is confusing, as clang-format is not
invoked by them, clang-tidy is. Hence rename those from
{manual_}clangformat() → {manual_}clangtidy()
`pathlib.Path.glob()` also returns directories that match source
filenames (i.e. a directory named `test.h/`), but `clang-format` and
`clang-tidy` fail when handed a directory. We manually skip calling
`clang-format` and `clang-tidy` on those directories.
This allows the NINJA environment variable to support all the Windows special
cases, especially allowing an absolute path without extension.
Based on a patch by Yonggang Luo.
Fixes: #7659
Suggested-by: Nirbheek Chauhan <nirbheek@centricular.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
D lang compilers have an option -release (or similar) which turns off
asserts, contracts, and other runtime type checking. This patch wires
that up to the b_ndebug flag.
Fixes#7082
Windows cmd.exe consoles may be using a code page that might choke
print() when we are outputting the output from calling gtk-doc. Let's
just ignore the error when it happens and print as much as we could in
this situation.
On Windows, prepend the commands to call the gtk-doc scripts using the
currently-used Python executable, since Windows cmd.exe consoles do not
support shebang lines.
We actually use this while linking on Windows, and hence we need to
extract symbols from this file, and not the DLL.
However, we cannot pass it instead of the DLL because it's an optional
output of the compiler. It will not be written out at all if there are
no symbols in the DLL, and we cannot know that at configure time. This
means we cannot describe it as an output of any ninja target, or the
input of any ninja target. We must pass it as an argument without
semantic meaning.
This gives a significant speedup in large projects such as gst-build
since now we only search for the tool once. Speed-up on Windows:
```
meson install:
before: 15.3 seconds
after: 5.4 seconds
meson install --only-changed:
before: 11.6 seconds
after: 2.7 seconds
```
-g is --extern-only and -P is --format=posix. We were missing
--defined-only for some reason, which we pass to `nm` on Linux.
This avoids having to manually filter later.
Some commands, notably gdb, use ctrl+c themselves to perform actions
without exiting. Instead of making meson exit and thus, kill the
subprocess, ignore the KeyboardInterrupt and continue waiting for
the child.
This is similar to what we currently do for scan-build except there is
no environment variable to choose a specific clang-format to run. If an
environment variable is needed for better control, we can add it later.
Detect scan-build the same way when trying to launch it and when
generating the target.
The detection method is:
1. look within SCANBUILD env variable
2. shutil.which('scan-build')
3. *on non-linux platforms only*: go through all the possible
name candidates and test them individually.
The third step is added following this comment
https://github.com/mesonbuild/meson/pull/5857#issuecomment-528305788
However, going through a list of all the possible candidates is neither
easily maintainable nor performant, and is therefore skipped on
platforms that should not require such a step (currently, only Linux
platforms).
This is a follow-up to the issue raised by @lantw44 during PR:
https://github.com/mesonbuild/meson/pull/5857
The size of WINEPATH is limited (1024 [until recently]), we
can very easily reach that limit, and even the new one (2048) so
try to keep path as small as possible by using the shortPath
version of paths.
Also assert that we do not reach the new hard limit.
And avoid having duplicates in the list of path.
[until recently]: https://bugs.winehq.org/show_bug.cgi?id=45810