In various situations we want to figure out what type of compiler we
have, because we want to know stuff like "is it the pgi one", or "does
it use msvc style". The compiler object has this property already, via
an API specifically designed to communicate this info, but instead we
performed isinstance checks on a compiler class.
This is confusing and indirect, and has the side effect of requiring
more imports everywhere. We should do away with it.
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.
assertTrue and assertFalse are recommended against, if you can get a
more specific assertion. And sometimes it is considerably shorter, for
example we have a custom assertPathExists which we can take advantage
of.
Eli Schwartz