The unittest case for `clang-tidy-fix` checks if the whole project is in
git or not, and skips if not.
Fix this by creating a temporary git repo, copy the test files and run
the tests, following how `clang-format` does.
It also reverts some help code introduced in the previous test.
Tested: Verify the test case passes.
Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Add the `clang-tidy-fix` target to apply clang-tidy fixes to the source
code.
This is done by calling `run-clang-tidy` with `-fix` argument.
Add a test case to run `clang-tidy-fix` and verify the file is changed.
Signed-off-by: Lei YU <yulei.sh@bytedance.com>
msys2 is broken only on clang, due to -Werror issues in the python
headers as patched by msys2.
MSVC is simply weird... due to the use of an unversioned platlib/purelib
directory, the python2 and python3 components overlap.
fix_jar() tries to remove an existing Class-Path entry from the jar
manifest by postprocessing the manifest and passing it to `jar -um`.
However, `jar -um` can only add/replace manifest entries, not remove
them, and it also complains loudly when replacing an entry:
Dec 13, 2022 7:11:19 PM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Manifest-Version.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
Thus fix_jar() produces one such warning for each entry in the manifest
and accomplishes nothing else.
Use jar -uM instead. This completely removes the manifest from the jar
and allows adding it back as a normal zip member, fixing fix_jar() and
avoiding the warnings.
Fixes: https://github.com/mesonbuild/meson/issues/10491
Fixes: c70a051e93 ("java: remove manifest classpath from installed jar")
This is treated by the test harness as though unset, i.e. we do normal
skipping and don't assume we are running in Meson's own project CI.
However, it has one distinction which is that it isn't an error to set
$CI without setting $MESON_CI_JOBNAME, if it is in fact set but to the
ignored value.
This lets automated workflows such as Linux distro testing, particularly
alpine linux, set $CI or have it set for them by default, without
messing things up.
Also it has the advantage of $CI actually enabling useful benefits! We
will still assume that this thirdparty environment wants to force
verbose logging (printing testlogs, running ninja/samu with -v) and
colorize the console.
The $CI environment variable may be generally set by Github or Gitlab
actions, and is not a reliable indicator of whether we are running "CI".
It could also, for an absolutely random example that didn't *just
happen*, be Alpine Linux's attempt to enable the Meson testsuite in
their packaging, which... uses Gitlab CI.
In this case, we do want to perform normal skipping on not-found
requirements. Instead of checking for $CI, check for $MESON_CI_JOBNAME
as we already use that in all of our own CI jobs for various reasons.
This makes it easier for linux distros to package Meson without
accumulating hacks like "run the testsuite using `env -u CI`".
The tests and the unittests both unconditionally call setup_vsenv()
because all tests are run using the backend commands directly: ninja,
msbuild, etc.
There's no way to undo this vs env setup, so the only way to test that
--vsenv works is by:
1. Removing all paths in PATH that provide ninja
2. Changing setup_vsenv(force=True) to forcibly set-up a new vsenv
when MESON_FORCE_VSENV_FOR_UNITTEST is set
3. Mock-patching build_command, test_command, install_command to use
`meson` instead of `ninja`
4. Asserting that 'Activating VS' is in the output for all commands
5. Ensure that compilation works because ninja is picked up from the
vs env.
I manually checked that this test actually does fail when the previous
commit is reverted.
Lei YU