Since vs backend only support the C compiler, everything else are custom
targets. Convert CompileTarget into a Generator to reuse existing code.
This will be useful in the future to support transpilers, and
assemblers.
%% survived into the output since 038b31e72b. That failed to fail, at
least in the common cases, because the whole command sequence is unnecessary /
redundant - it appears to come from cmake, which executes multiple commands
within a single CustomBuild element.
Regardless of which MachineChoice we base the platform on, we compare
its value to lowercased identifiers. So we need to lowercase the
targetplatform too... but we only did so sometimes.
This broke e.g. on "Win32", but only when *not* doing a cross build.
Fixes#10539
A single target could be picked for unity build, and in that case
extract_objects() should not be allowed.
Likewise for the opposite case, where extract_objects() should be allowed
if unity build is disabled for a single target. A test that covers that
case is added later.
'meson-test-prereq' now depends on any targets that were formerly added
directly to 'all'. Behavior is not changed -- the all target still
depends on this other meta-rule, and thus indirectly depends on all
targets it used to depend on.
It is now possible to build just the targets needed for the testsuite
and then e.g. run `meson test --no-rebuild`.
Since they are actually dependencies out the output not the Generator
itself.
This fixes dependency issues in the ninja backend, allowing Meson to
rebuild more accurately. It also does sometimes in the vs backend, but
there are problems in the vs backend I'm not sure how to solve. The
vsbackend is, itself, so fragile looking I don't want to get too
involved with it.
This doesn't actually fix the problem, but it provides parity with what
is currently happening. I don't have access to a Windows machine to
further debug, however, so not breaking anything is the best I can do
ATM.
That method had nothing specific to the backend, it's purely a Target
method. This allows to cache the OptionOverrideProxy object on the
Target instance instead of creating a new one for each option lookup.
fixes#6314
in case of backend is vs2017 or vs2019 place LanguageStandard tag with stdcpp version and LanguageStandard_C tag with stdc version in .vcxproj file
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.
Xavier Claessens
Luke Elliott
Dylan Baker
Caleb Cornett
Vili Väinölä
Andres Freund
Tad Young
Paolo Bonzini
Eli Schwartz
Crend King
GustavoLCR
Moroz Oleg
Олег Мороз
Christian Clauss
Simon Ser
Daniel Mensinger
fanc999
Peter Harris
Jussi Pakkanen
Jesse Natalie
Matthias Klumpp