Age | Commit message (Collapse) | Author | Files | Lines |
|
There is no reason why meson should swallow any non-zero exit(/return)
code of clang-format.
|
|
It turns out my first attempt to fix this in 00d5ef3191e5 ("Fix
clang-tidy return value reporting (#7949)") is not sufficient: The
local variable returncode is never updated and stays at 0. This fixes
the returncode calculation.
Fixes: cce172432be3 ("Use run-clang-tidy when available.")
|
|
* 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()
|
|
|
|
* fix 5492 with cleaner code
* remove argparse import
* replace list(map( with list comprehension
* pass str rather than Path to get_cmd_line_file
|
|
by default run_clang_tidy process al file in compile_commands.json but
the file generated has to be esclude like already done from
manual_clangformat
|
|
`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.
|
|
Make 'meson --internal exe --unpickle' report the actual command
executed when it fails, which is otherwise invisible.
|
|
|
|
|
|
This adds an experimental meson module to build projects with other
build systems.
Closes: #4316
|
|
|
|
|
|
|
|
|
|
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>
|
|
I can't reproduce this, but it is definitely possible. In this case
what we should do is the same as when the tool is not found.
Fixes https://github.com/mesonbuild/meson/issues/7605
|
|
|
|
|
|
It's equivalent to copyfile + copystat with the same arguments.
|
|
|
|
As suggested by dcbaker in
https://github.com/mesonbuild/meson/pull/7370#pullrequestreview-436872661
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
mesonbuild/scripts/cmake_run_ctgt.py, as well as enclose everything in a run() function so it can be called by `meson --internal cmake_run_ctgt ...`. Also, include mesonbuild/cmake/data/ in the msi package.
|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
|
|
Also do Windows loader specific PATH adjustment (to emulate rpath) in
gtkdochelper for Cygwin.
|
|
Let .pc files and LDFLAGS provide rpaths.
|
|
|
|
Fixes #4027
|
|
This will almost always change and cause a relink of everything. Our
other symbol extractor implementations do not store this either. We
only need to store the size of data objects, since that necessitates
a relink due to copy relocations.
Drastically reduces the amount of relinking required in gstreamer and
gtk on Linux.
|
|
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.
|
|
Use the GNU toolchain for that.
|
|
It is not specific to Linux but works with the GNU toolchain, so
give it a better name.
No functional changes.
|
|
mesonbuild/nirbheek/implement-symbolextractor-windows
Implement symbolextractor on windows + some cleanups/fixes
|
|
|
|
Requires the latest LLVm 9.0 release which implements the `-list`
argument to `llvm-lib` and ships with an implementation of `nm` called
`llvm-nm`.
|
|
Supports both MSVC and MinGW toolchains. Checks for MSVC first, then
falls back to MinGW.
|
|
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.
|
|
Generated headers, PDB files, import libraries, etc.
Speed-up in gst-build on Windows:
```
meson install
before: 5.4 seconds
after: 5.1 seconds
meson install --only-changed
before: 2.7 seconds
after: 1.6 seconds
```
|
|
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
```
|
|
|
|
This is how we parse all env vars for tools in Meson. Do the same here
too for consistency.
|
|
Also write out a dummy symbols file if the tool wasn't found or didn't
work instead of just spewing an exception.
|
|
-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.
|
|
So people know why all their binaries are getting relinked. Do this
only once per build-dir by writing a file to meson-private.
|
|
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.
|
|
|
|
|
|
|