* 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`.
Executables may have an entry point of wmain or wWinMain. These
executables link successfully with ninja. Rather than add more flags to
executable() in meson.build, remove the EntryPointSymbol override. This
makes the vs backend behave more like the ninja backend.
Fixes#6698
Visual Studio refuses to open projects that present duplicated
items, for example:
<ItemGroup>
<CLInclude Include="glib-enumtypes.h"/>
<CLInclude Include="glib-enumtypes.h"/>
</ItemGroup>
Note that MSBuild handles duplicated items without any issue,
this is useful only for compatibility with the VS IDE.
See pull request mesonbuild#6151
Fixes issue mesonbuild#6147
Return the command line from serialize_executable, which is then
renamed to as_meson_exe_cmdline. This avoids repeating code that
is common to custom targets and generators.
Dylan Baker
GustavoLCR
Simon Ser
Daniel Mensinger
fanc999
Peter Harris
Jussi Pakkanen
Jesse Natalie
Eli Schwartz
Matthias Klumpp
Xavier Claessens
Ben Niu
Vili Väinölä
Jon Turney
Nirbheek Chauhan
John Ericson
Marc-André Lureau
Luca Bacci
Paolo Bonzini