UseMultiToolTask allows parallelism inside a project, without requiring cl.exe
internal multi-threading (which meson generated projects currently can't use,
mainly due to specifying output filenames for each object).
TODO:
- think about making behaviour conditional on msbuild version / add comment
why not
The main reason for this move is to make it easier to merge the copies of
project generation. But as far as I can tell, the Microsoft.Cpp.props import
also belongs before the ItemDefinitionGroup.
Originally the order seems to have been that way, but 431a9ea664 changed it in
the course of other changes.
When a static library B to a static library A with generated sources, B
directly references the object file corresponding to the generated source in
A. For that reference in B object_filename_from_source() is used. But A did
not specify the object file name, ending up with cl.exe's default.
Fixes: #9235
Alias commands did not work with the vs backend, due to trying to access
target.command[0] with an empty command. Fix this by just not emitting a
CustomBuild node for alias targets - the project references are enough to
trigger the necessary actions.
Fixes: #9247
This caught a couple of cases of us doing:
```python
for i in range(len(x)):
v = x[i]
```
which are places to use enumerate instead.
It also caught a couple of cases of:
```python
assert len(x) == len(y)
for i in range(len(x)):
xv = x[i]
yv = y[i]
```
Which should instead be using zip()
```python
for xv, yv in zip(x, y):
...
```
We have a lot of these. Some of them are harmless, if unidiomatic, such
as `if (condition)`, others are potentially dangerous `assert(...)`, as
`assert(condtion)` works as expected, but `assert(condition, message)`
will result in an assertion that never triggers, as what you're actually
asserting is `bool(tuple[2])`, which will always be true.
* 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.
* 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
Without this, VS will generate
warning MSB8065: Custom build for item "<path>\custom_target.rule" succeeded, but specified output "<path>\outofdate.file" has not been created. This may cause incremental build to work incorrectly.
Re-implement it in backend using the same code path as for
custom_target(). This for example handle setting PATH on Windows when
command is an executable.
ARM64EC is a new ARM64 ABI made by Microsoft. The ARM64EC binaries can be loaded in x64 processes on the latest Windows Insider Preview on ARM64, and they don't need to be emulated for the sake of performance.
To support the ARM64EC build target, a new conceptual arm64 cpu type 'arm64ec' is added. The cpu can be specified in cross files like below to generate msbuild solution/vcxproj files with platform set to ARM64EC.
[target_machine]
system = 'windows'
cpu_family = 'aarch64'
cpu = 'arm64ec'
endian = 'little'
This patches takes the options work to it's logical conclusion: A single
flat dictionary of OptionKey: UserOptions. This allows us to simplify a
large number of cases, as we don't need to check if an option is in this
dict or that one (or any of 5 or 6, actually).
I would have prefered to do these seperatately, but they are combined in
some cases, so it was much easier to convert them together.
this eliminates the builtins_per_machine dict, as it's duplicated with
the OptionKey's machine parameter.
- Fixed using debug and optimization built-in options in MSVC.
- Fixed that VS backend does not create pdb files in release mode.
VS implicitly adds the debug fields if left out.
- Fix that it is possible to add debug info with ninja backend with
optimizations.
I've always found ninja reporting 'a meson_exe.py custom command'
unclear and confusing. Instead say we are invoking a custom command,
wrapped by meson, and why.
- "Go To Document" action previously only worked
on c/cpp files which had the include directories
set but it was not possible to move from header to another header.
Since the CompileArgs class already needs to know about the compiler,
and we really need at least per-lanaguage if not per-compiler
CompilerArgs classes, let's get the CompilerArgs instance from the
compiler using a method.
When changing meson option cpp_eh, it was passed to cl with AdditionalOptions and resulted in unsuppressable warning "cl : command line warning D9025: overriding '/EHs' with '/EHa'"
Use the IDE's OpenMP flag instead of adding /openmp to additional
arguments. The IDE appears to override /openmp in additional arguments
with the IDE setting, which defaults to false, leading to binaries built
without OpenMP.
D lang compilers have an option -release (or similar) which turns off
asserts, contracts, and other runtime type checking. This patch wires
that up to the b_ndebug flag.
Fixes#7082
It is not unheard-of for a project to use pch for C++ but not for C
(because C usually builds fast enough anyway, so it's not worth the
developer overhead of maintaining the pch file).
This code was trying to optimize the vcxproj file size by detecting
"only one language", but it was only looking at the number of
pch-languages defined. This is incorrect when pch is not defined for all
languages in use.
Instead of tweaking the optimization further, remove it. This makes the
vs backend behave more like the ninja backend.
A current rather untyped storage of options is one of the things that
contributes to the options code being so complex. This takes a small
step in synching down by storing the compiler options in dicts per
language.
Future work might be replacing the langauge strings with an enum, and
defaultdict with a custom struct, just like `PerMachine` and
`MachineChoice`.
Christian Clauss
Andres Freund
Eli Schwartz
Dylan Baker
GustavoLCR
Simon Ser
Daniel Mensinger
fanc999
Peter Harris
Jussi Pakkanen
Jesse Natalie
Matthias Klumpp
Xavier Claessens
Ben Niu
Vili Väinölä
Jon Turney
Nirbheek Chauhan
John Ericson