* backends: Add a Visual Studio 2013 backend
This is more-or-less a quick port from the VS2015 backend, except that
we update the Visual Studio version strings and toolset versions
accordingly. Also correct the generator string for Visual Studio 2015
in mesonbuild/cmake/common.py.
* backend: Add VS2012 backend
Similar to what we did for Visual Studio 2013, add a Visual Studio 2012
backend.
* vs2010backend.py: Implement `link_whole:` if needed
We actually need Visual Studio 2015 Update 2 to use `/WHOLEARCHIVE:`,
which is what we are currently using for `link_whole:` on Visual Studio.
For Visual Studio versions before that, we need to expand from the
static targets that were indicated by `link_whole:`, and any of the
sub-dependent targets that were pulled in via the dependent target's
`link_whole:`. This wil ensure `link_whole:` would actually work in
such cases.
* vs2010backend.py: Handle objects from generated sources
Unforunately, we can't use backends.determine_ext_objs() reliably, as
the Visual Studio backends handle this differently.
* vs2010backend.py: Fix generating VS2010 projects
Visual Studio 2010 (at least the Express Edition) does not set the envvar
%VisualStudioVersion% in its command prompt, so fix generating VS2010
projects by taking account into this, so that we can determine the location
of vcvarsall.bat correctly.
* whole archive test: Disable on vs2012/2013 backends too
The Visual Studio 2012/2013 IDE has problems handling the items that would be
generated from this test case, so skip this test when using
--backend=vs[2012|2013]. This test does work for the Ninja backend when
VS2012 or VS2013 is used, though.
Consolidate this error message with XCode along with the vs2010 backend.
* docs: Add the new vs2012 and vs2013 backends
Let people know that we have backends for vs2012 and 2013. Also let
people know that generating Visual Studio 2010 projects have been fixed
and the pre-vs2015 backends now handle the `link_whole:` project option.
There's no reason to allow None into the backend, it already has code to
check that all of the values of the FileMode object are None, so let's
use that, which is much simpler all the way down.
This is a follow-up to gh-8706, which contained the initial fix
to ninjabackend.py but somehow lost it. This re-applies the fix
and adds a test for it.
Without the fix, the error is:
ninja: error: 'ct2.pyx', needed by 'libdir/ct2.cpython-39-x86_64-linux-gnu.so.p/ct2.pyx.c',
missing and no known rule to make it
When mutable items are stored in an lru cache, changing the returned
items changes the cached items as well. Therefore we want to ensure that
we're not mutating them. Using the ImmutableListProtocol allows mypy to
find mutations and reject them. This doesn't solve the problem of
mutable values inside the values, so you could have to do things like:
```python
ImmutableListProtocol[ImmutableListProtocol[str]]
```
or equally hacky. It can also be used for input types and acts a bit
like C's const:
```python
def foo(arg: ImmutableListProtocol[str]) -> T.List[str]:
arg[1] = 'foo' # works while running, but mypy errors
```
...Update 2, to be exact, since the Visual Studio linker only gained the
`/WHOLEARCHIVE:` feature since Visual Studio 2015 Update 2.
This checks whether we have the corresponding `cl.exe` which is
versioned at or after Visual Studio 2015 Update 2 before we try to apply
the `/WHOLEARCHIVE:xxx` linker flag. If we aren't, use built-in methods
in Meson to grab the object files of the dependent static lib's, along
with the objects that were `link_whole:`'ed into them, and feed this
list into the linker instead.
This would make `link_whole:` work on Visual Studio 2015 Update 1 and
earlier, including previous Visual Studio versions.
* Allow address sanitizer for Visual Studio 2019 version 16.9
Address Sanitizer was first supported with the current syntax in Visual
Studio 16.9.0 (cl version 19.28.29910).
* VS: Convert /fsanitize=address to project file setting
When pch are used for a target meson will make the compiler to include
the pre-compiled header. While this is useful, this needs to happen
before any other header has been included, otherwise:
1) we won't take advantage of pch for anything else previously included
2) gcc will just fail as it won't even try to look for a pre-compiled
header in this case [1]
This case can happen quite a easily when a dependency provides an
included header in its cflags.
As per this, split _generate_single_compile() in two phases, one is
responsible of initializing the compiler data, while the other is
defining commands for the context.
In this way, when pch can be used, we can insert the pch inclusion
earlier than any other provided by the target.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
Daniel Mensinger