This patch adds a new meson built-in option for cython, allowing it to
target C++ instead of C as the intermediate language. This can, of
course, be done on a per-target basis using the `override_options`
keyword argument, or for the entire project in the project function.
There are some things in this patch that are less than ideal. One of
them is that we have to add compilers in the build layer, but there
isn't a better place to do it because of per target override_options.
There's also some design differences between Meson and setuptools, in
that Meson only allows options on a per-target rather than a per-file
granularity.
Fixes#9015
This really is more of a struct than a dict, as the types are disjoint
and they are internally handled, (ie, not from user input). This cleans
some things up, in addition I spotted a bug in the ModuleState where the
dict with the version and license is passed to a field that expects just
the version string.
When setup creates a Visual Studio environment, a message is logged
which contains a path to the build directory. Typically, this path is
converted to a relative path prior to printing. If the path cannot be
converted to a relative path (e.g., because buildpath is on a different
drive from the cwd), print out the full path instead of failing with an
unhandled exception.
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
Since we changed to using a json file to avoid over long command lines
we created a situation where the generated files may not be ready when
the depscan happens. To avoid that, we need to add all of the generated
sources as order deps.
Fixes: #9258
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.
This didn't actually catch what it's supposed to, which is cases of:
```python
for x in dict.keys():
y = dict[x]
```
But it did catch one unnecessary use of keys(), and one case where we
were doing something in an inefficient way. I've rewritten:
```python
if name.value in [x.value for x in self.kwargs.keys() if isinstance(x, IdNode)]:
```
as
``python
if any((isinstance(x, IdNode) and name.value == x.value) for x in self.kwargs):
```
Which avoids doing two iterations, one to build the list, and a
second to do a search for name.value in said list, which does a single
short circuiting walk, as any returns as soon as one check returns True.
Currently, we write each file to the command line, but this can result in
situations where the number of files passed exceeds OS imposed command
line limits. For compilers, we solve this with response files. For
depscan I've chosen to use a JSON list instead. JSON has several
advantages in that it's standardized, there's a built-in python module
for it, and it's familiar. I've also chosen to always use the JSON file
instead of having a heuristic to decide between JSON and not JSON,
while there may be a small performance trade off here, keeping the
implementation simple with only one path is wort it.
Fixes#9129
Sonarcloud.io only can read the sonarqube based report that gcovr can
produce. This change enables support for this output in meson and
ninja.
Signed-off-by: Weston Schmidt <Weston_Schmidt@alumni.purdue.edu>
For an ELF targets, shared_module() builds a module with SONAME field
(using -Wl,-soname argument). This is wrong: only the shared_library()
needs SONAME, while shared_module() does not. Moreover, tools such as
debian's dpkg-shlibdeps use presence of SONAME field as an indicator
that this is shared library as opposed to shared module (e.g., for the
module it is okay to have unresolved symbols which are imported from
the executable which loads the module, while a library should have all
symbols resolved).
This was in fact already the behavior on Darwin; extend it to ELF
targets as well.
Fixes: #8746
Reported-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Currently all arguments are being passed to scan-build as part of the
refactoring of how Meson internally handles arguments, but that's wrong,
only project specific arguments are supposed to be passed.
Fixes: #8818
* 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.
Dylan Baker
Ryan Kuester
Andres Freund
Xavier Claessens
Eli Schwartz
Filipe Laíns
Jussi Pakkanen
Nirbheek Chauhan
GustavoLCR
Weston Schmidt
Paolo Bonzini
Simon Ser
Daniel Mensinger
Denis Fortin
fanc999