diff options
author | Nirbheek Chauhan <nirbheek@centricular.com> | 2022-01-16 16:01:33 +0530 |
---|---|---|
committer | Nirbheek Chauhan <nirbheek.chauhan@gmail.com> | 2022-01-16 23:42:19 +0530 |
commit | faf79f4539841cbf89fe8d53cf35aa91fd8273c9 (patch) | |
tree | d6d4eaf7caae6681714cc97c56dd2ff1b73e5329 /mesonbuild/interpreter/interpreterobjects.py | |
parent | 1cda222a1a5faf98bf5c72bc103307bf76f76f7f (diff) | |
download | meson-faf79f4539841cbf89fe8d53cf35aa91fd8273c9.zip meson-faf79f4539841cbf89fe8d53cf35aa91fd8273c9.tar.gz meson-faf79f4539841cbf89fe8d53cf35aa91fd8273c9.tar.bz2 |
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.
Diffstat (limited to 'mesonbuild/interpreter/interpreterobjects.py')
0 files changed, 0 insertions, 0 deletions