The `debug` builtin option does not control whether or not the debug
CRT is used. Without this fix, when buildtype=debugoptimized or when
debug=true + b_vscrt=md, we will try to link to the debug libraries
found via cmake while linking with `/release`, which will cause a link
failure.
There is nothing to "warn" about, this is a completely routine
occurence. OTOH, when something is corrupted, we should warn. Keep
the red color and "WARNING:" prefix in that case.
Example output:
$ ninja -C build
Regenerating configuration from scratch: Build directory has been generated with Meson version 0.55.999, which is incompatible with current version 0.56.0.
The Meson build system
Version: 0.56.0
...
Fixup for b4b1a2c5a1.
A warning would be printed for any rule with multiple outputs, for
example:
WARNING: custom_target 'coredump.conf.5' has more than one output! Using the first one.
WARNING: custom_target 'dnssec-trust-anchors.d.5' has more than one output! Using the first one.
WARNING: custom_target 'halt.8' has more than one output! Using the first one.
Fixes https://github.com/systemd/systemd/issues/16461.
'native:' keyword was only added in 0.54. For projects declaring
meson_version >= 0.54, warn, because those projects can and should set
the keyword. For older projects declaring support for older versions,
don't warn and use the default implicitly.
Fixes https://github.com/mesonbuild/meson/issues/6849.
Since -Wl,-rpath= is not the only valid rpath ldflags syntax we
need to try and match all valid rpath ldflags.
In addition we should prevent -Wl,--just-symbols from being used to
set rpath due to inconsistent compiler support.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
otherwise we are getting errors like:
Traceback (most recent call last):
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/mesonmain.py", line 131, in run
return options.run_func(options)
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/msetup.py", line 245, in run
app.generate()
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/msetup.py", line 159, in generate
self._generate(env)
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/msetup.py", line 215, in _generate
intr.backend.generate()
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/backend/ninjabackend.py", line 518, in generate
self.generate_coverage_rules()
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/backend/ninjabackend.py", line 991, in generate_coverage_rules
self.generate_coverage_command(e, [])
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/backend/ninjabackend.py", line 975, in generate_coverage_command
for compiler in target.compilers.values():
AttributeError: 'RunTarget' object has no attribute 'compilers'
This extends the 109 generatecode test case to also define a test, so
coverage can really detect something.
This avoid printing long backtrace by default, the user already has the
output of the git command printed for debugging purpose since we don't
redirect stdout/stderr.
Add depfile support to generated targets for Qt >= 5.14.
Move warning into the module init itself, to check if the version is too
old before issuing. Also tweak the wording itself, to advise upgrading
to a suitable version of Qt5 instead of advising to wait for a Qt bug to
be fixed.
I made the mistake of always selecting the debug CRT for compiler
checks on Windows 4 years ago:
https://github.com/mesonbuild/meson/pull/543https://github.com/mesonbuild/meson/pull/614
The idea was to always build the tests with debugging enabled so that
the compiler doesn't optimize the tests away. But we stopped doing
that a while ago, and also the debug CRT has no relation to that.
We should select the CRT in the same way that we do for building
targets: based on the options.
On Windows ARM64, the debug CRT for ARM64 isn't always available, and
the release CRT is available only after installing the runtime
package. Without this, we will always try to pick the debug CRT even
when --buildtype=debugoptimized or release.
Some warnings are out of the user's control, such as the RCC QT bug,
or the GNU windres bug, or our informational warning about
auto-disabling of options when -Db_bitcode is enabled.
Such warnings should not be fatal when --fatal-meson-warnings is
passed because there's no action that the user can take to fix it. The
only purpose it serves is to prevent people who use those features
from using --fatal-meson-warnings.
On some systems aarch64 is reported as arm64. Due to mesons
mangling of everything that starts with arm, it would end up being
detected as arm (which implies 32 bit) which is incorrect.