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
This previously worked because we were accidentally doing this via
mutation. However, doing this via mutation is not a good way to do it,
we should be explicit.
Fixes#9542
This ensures that there is no warnings when running meson on
test cases/common/22 object extraction.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Make the handling of bindgen inputs consistent with the inputs and outputs of
source_strings_to_files.
However, for the first source argument reject anything that cannot
possibly be an header file. This also fixes a mypy failure from the next
patch, since ExtractedObjects does not have a zero-argument get_outputs
method.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
As evidenced by the warning message immediately below this, I meant to
write "5.15" here. As is, this will enable depfile support on too-old
versions of moc.
Currently, if you pass a `[]string`, but the argument expects
`[]number`, then you get a message like `expected list[str] but got
list`. That isn't helpful. With this patch arrays and dictionaries will
both print messages with the types provided.
Calling interpreter implementation methods is just a bad idea, apart
from the extra type checking that goes into it, we need to pass more
arguments than we need to calling the impl method.
This also includes a few type annotation cleans for the Summary object.
Getting the positional arguments exactly right is impossible, as this is
really a function with two different signatures:
```
summary(value: dictionary): void
summary(key: string, value: any): void
```
We can get close enough in the typed_pos_args by enforcing that there
are two parameters, one required and one optional, and that the first
must be either a dictionary or a string.
It works fine as-is with an empty list, and since that's easier to get
using our typed_kwargs, and thus is what we're passing, go ahead and
simplify the class to only take a list of strings.
The inner closure of the typed_kwargs function is already complicated
enough without defining closures in the middle of a loop. Let's just
pass the types_tuple as an argument to both avoid redefining the
function over and over, and also make the whole thing easier to read.
Whilst working on the Reproducible Builds effort [0], I noticed that meson did
not generate reproducible .cmake files: they include the full path name.
This commit not only makes the build reproducible, but it also matches CMake's
own behaviour. Specifically, CMakePackageConfigHelpers.cmake does the
equivalent transformation using:
get_filename_component(inputFileName "${_inputFile}" NAME)
I originally filed this in Debian as bug #1000327 [1].
[0] https://reproducible-builds.org/
[1] https://bugs.debian.org/1000327
Contrary to most system method checks, zlib currently functions as a
whitelist of OSes. This isn't really needed however. The first special
case for OSes that provide zlib as part of the base OS is worth keeping.
However, the elif for windows is more than generic enough to allow any
other potential OSes to try. Just make it a simplie if/else instead.
Since these aren't warnings, per se, we don't note every single call
site that has one. And we raise mlog.notice in non-fatal mode to avoid
either:
- being too threatening
- making builds fail with --fatal-meson-warnings
Nevertheless, it is useful to give people a heads-up that there is an
upgrade opportunity, rather than waiting until they upgrade and then
causing projects to begin printing fatal warnings.
mlog can already print location info, and we use this often -- including
for custom feature warnings already. Make this work everywhere, so that
it is feasible to move such custom warnings to globally tracked
Features.
This is only relevant on certain versions of meson, so do not print it
when meson_version is too low.
The message itself is not precisely a deprecation warning, since
ostensibly it may be an unlikely coding mistake. It is probably an
attempt to implement `copy: true`, but it might not be, hence "warning"
instead of "deprecation". So although we could switch this to a
FeatureDeprecated, that is not being done at this time.
We went straight to the extra message, which when parsed as a subproject
string resulted in the Feature being entirely skipped because "project()
has not been parsed yet" as it could not find a subproject named that.
This tries to link the system provided python, which is deprecated and
will result in an ambiguous error like "your binary is not an allowed
client of .../Library/Frameworks/python.framework/python.tbd for
architecture x86_64".
Depending on whether hdf5 is compiled with parallel support, the
same config-tool program may be installed with a mysterious "p" in the
name. In this case, dependency lookup will totally fail, unless of
course you use the superior pkg-config interface in which case you get a
predictable name.
Work around this insanity by checking for both types of config-tool
name.
Fixes#9555
When input kwarg is missing in i18n.merge_file() it was crashing with a
backtrace because of kwargs['input'][0]. That code was useless anyway
because CustomTarget now uses first output as default name which is what
we need here.
Nirbheek Chauhan
Dylan Baker
Pablo Correa Gómez
Paolo Bonzini
Eli Schwartz
Denis Feklushkin
Luke Drummond
Chris Lamb
Crend King
GustavoLCR
Dudemanguy
Jon Turney
Xavier Claessens