Chiebot-Mirror/meson - meson - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Benjamin Gilbert	35e230e48c	depfixer: silence fix_jar() and make it do something 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")	2 years ago
Dylan Baker	6c5a0f8332	unittests: Fix rpath tests no nixos Which insert a bunch of rpath entries we strip, but then don't check if they're empty and fail anyway.	3 years ago
Eli Schwartz	a580fac83a	tests: allow setting MESON_CI_JOBNAME=thirdparty 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.	3 years ago
Eli Schwartz	4274e0f42a	unittests: fine-tune the check for whether we are in CI 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`".	3 years ago
Nirbheek Chauhan	faf79f4539	Add a test for the --vsenv meson setup option 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.	3 years ago
Xavier Claessens	7eb4c23156	Split run_unittests.py file	3 years ago