This is a pretty common pattern in python (the standard library uses it
a ton): A class is created, with a single private instance in the
module, and then it's methods are exposed as public API. This removes
the need for the global statement, and is generally a little easier to
reason about thanks to encapsulation.
The stdlib unittest module has a magic flag (undocumented) which
indicates that a module is part of a unittest framework.
> Truncates usercode tb at the first unittest frame.
>
> If the first frame of the traceback is in user code,
> the prefix up to the first unittest frame is returned.
> If the first frame is already in the unittest module,
> the traceback is not modified.
This avoids some ugliness, e.g. the following test error logs:
```
> self.assertPathListEqual(intro[0]['install_filename'], ['/usr/lib/libstat.aaa'])
unittests/allplatformstests.py:432:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
unittests/baseplatformtests.py:393: in assertPathListEqual
self.assertPathEqual(i[0], i[1])
unittests/baseplatformtests.py:384: in assertPathEqual
self.assertEqual(PurePath(path1), PurePath(path2))
E AssertionError: PurePosixPath('/usr/lib/libstat.a') != PurePosixPath('/usr/lib/libstat.aaa')
```
Since assertPathListEqual is our own assertion helper, we don't need to
give trace information about its internals. This change causes the error
log to become:
```
> self.assertPathListEqual(intro[0]['install_filename'], ['/usr/lib/libstat.aaa'])
E AssertionError: PurePosixPath('/usr/lib/libstat.a') != PurePosixPath('/usr/lib/libstat.aaa')
unittests/allplatformstests.py:432: AssertionError
```
which is a lot more readable.
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.
CI runs with vs2019 and we were passing --backend=vs. This fix
reconfigure tests because we can't reconfigure with --backend=vs when
initial configuration determined the backend is actually vs2019.
It can only be used for projects that don't have any rules at all, i.e.
they are purely using Meson to:
- configure files
- run (script?) tests
- install files that exist by the end of the setup stage
This can be useful e.g. for Meson itself, a pure python project.
Factors out opening the meson log into its own function so that
it can be used in the places where with was done before.
Additionally instead of checking if the file exists before opening it,
try to open it and handle the exception when it is not found.
This is ambiguous, if the build directory has the same name as a
subcommand then we end up running the subcommand. It also means we have
a hard time adding *new* subcommands, because if it is a popular name of
a build directory then suddenly scripts that try to set up a build
directory end up running a subcommand instead.
The fact that we support this at all is a legacy design. Back in the
day, the "meson" program was for setting up a build directory and all
other tools were their own entry points, e.g. `mesontest` or
`mesonconf`. Then in commit fa278f351f we
migrated to the subcommand mechanism. So, for backwards compatibility,
we made those tools print a warning and then invoke `meson <tool>`. We
also made the `meson` tool default to setup.
However, we only warned for the other tools whose entry points were
eventually deleted. We never warned for setup itself, we just continued
to silently default to setup if no tool was provided.
`meson setup` has worked since 0.42, which is 5 years old this week.
It's available essentially everywhere. No one needs to use the old
backwards-compatible invocation method, but it continues to drag down
our ability to innovate. Let's finally do what we should have done a
long time ago, and sunset it.
We only want to scan stdout for these strings, and particularly, if we
allow `-d explain` to be mingled into stdout, then buffering issues
across OSes can lead to inaccurate results.
For example:
```
meson builddir \
--native-file vs2019-paths.txt \
--native-file vs2019-win-x64.txt \
--cross-file vs2019-paths.txt \
--cross-file vs2019-win-arm64.txt
```
This was causing the error:
> ERROR: Multiple producers for Ninja target "/path/to/vs2019-paths.txt". Please rename your targets.
Fix it by using a set() when generating the list of regen files, and
add a test for it too.
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.
Two tests are failing on Cygwin because the argument is passed as
a long-path and the Path is ending up as a short-path:
AllPlatformTests.test_run_target_files_path
Traceback (most recent call last):
File "/cygdrive/d/a/meson/meson/test cases/common/51 run target/check-env.py", line 22, in <module>
assert build_root == env_build_root
AssertionError
SubprojectsCommandTests.test_purge
> self.assertEqual(deleting(out), sorted([
str(self.subprojects_dir / 'redirect.wrap'),
str(self.subprojects_dir / 'sub_file'),
str(self.subprojects_dir / 'sub_git'),
]))
E AssertionError: Lists differ: ['/cygdrive/c/Users/runneradmin/AppData/Local/Temp/tmpeaa2a49[205 chars]git'] != ['/cygdrive/c/Users/RUNNER~1/AppData/Local/Temp/tmpeaa2a49z/s[196 chars]git']
[...]
['/cygdrive/c/Users/runneradmin/AppData/Local/Temp/tmpeaa2a49z/src/subprojects/redirect.wrap',
^^^^^^^^^^^
['/cygdrive/c/Users/RUNNER~1/AppData/Local/Temp/tmpeaa2a49z/src/subprojects/redirect.wrap',
^^^^^^^^
The fix is to not use the tempdir for all tests, but only for tests
that check the mode.
Clippy is a compiler wrapper for rust that provides an extra layer of
linting. It's quite popular, but unfortunately doesn't provide the
output of the compiler that it's wrapping in it's output, so we don't
detect that clippy is rustc. This small patch adds a new compiler class
(that is the Rustc class with a different id) and the necessary logic to
detect that clippy is in fact rustc)
Fixes: #8767
This adds a new keyword argument to the init method, `allow_fail`. When
set to True (default is False) then a failure to configure is not an
error, and output is still returned. This can be useful for cases where
we expect initialization to fail, and want to check the output.
There are two problems with having this in the try/except block. The
first is that both of the if statements will raise, and the except
statement cathces `Exception`, so it catches these two cases, prints a
message that we either don't want or already printed, then re-raises.
Charles Brunet
Eli Schwartz
Dylan Baker
Xavier Claessens
Marvin Scholz
Nirbheek Chauhan