Android requires shared modules that use symbols from other shared
modules to be linked before they can be dlopen()ed in the correct
order. Not doing so leads to a missing symbol error:
https://github.com/android/ndk/issues/201
We need to always allow linking for this. Also add a soname, although
it's not confirmed that it's needed, and it doesn't really hurt if it
isn't needed.
For static library crates that depend on other internal static library
crates, all link_with targets get promoted to link_whole targets. Due to
a bug, only link_with targets are considered when generating a Rust
target for the ninja backend. This made it impossible to link a Rust
static library with another internal Rust static library.
This change fixes that issue by chaining link_whole_targets with
link_targets, just like many other languages within the ninja backend.
Basically the last thing we did during target processing was to generate
shlib symlinks for e.g. libfoo.so -> libfoo.so.1.
In some cases we would dispatch to another function and return early,
though, which meant we never got far enough to generate the symlinks.
This then led to breakage when people tried to compile against libfoo.so
This surely breaks -uninstalled.pc usage, and also caused problems in
https://github.com/rust-lang/rust/pull/90260
When a custom_target() uses an env, meson uses a wrapper
script to run the executable. This breaks the console: kwarg
because the wrapper script buffers the output. Fix it by setting
the verbose flag which will not buffer output.
Emit a detailed deprecation warning that explains what to do instead.
Also add a unittest.
```
DEPRECATION: target prog links against shared module mymod, which is incorrect.
This will be an error in the future, so please use shared_library() for mymod instead.
If shared_module() was used for mymod because it has references to undefined symbols,
use shared_libary() with `override_options: ['b_lundef=false']` instead.
```
Fixes https://github.com/mesonbuild/meson/issues/9492
We say:
> If version 4.2 or higher of the first is found, targets coverage-text,
> coverage-xml, coverage-sonarqube and coverage-html are generated.
But this is totally untrue. Make it true, by actually checking (and
not generating broken coverage commands when older versions of gcovr are
found).
Fixes#9505
Since they will never be used outside of the build directory, they do
not need to literally contain the .o files, and references will be
sufficient.
This covers a major use of object libraries, which is that the static
library would potentially take up a lot of space by including another
copy of every .o file.
Fixes#9292Fixes#8057Fixes#2129
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
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.
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
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.
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
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
```