It never made sense here to save self.init() which returns a string
containing a log or stdout or something, and which was never actually
used.
Also we then overwrote the variable with a pathname...
In commit d932cd9fb4, we migrated to
meson's own static linker definition, and the old code that hardcoded
two of the possible exelists should have been removed in the process.
It has always been working even if not documented and there is no reason
to not accept it. However, change "True/False" to "true/false" to be
consistent with meson language.
Fixes: #9436
It's not a python file, so it will never end up in the installed package
unless we mark it as package_data. This causes problems for people using
non-git checkouts.
Fixes#9435Closes#9443
NamedTemporaryFile can't be opened by name on Windows.
For Windows the created temporary bat file is now closed before
passing to a subprocess, prevented from removal automatically upon
close and deleted explicitly upon finish.
e7c972b606
added PACKAGE_VENDOR to lld, causing the -v output to start with "Homebrew LLD"
rather than just "LLD". Meson no longer detects it and fails the
test_ld_environment_variable_lld unit test.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
If meson is not a process group leader, a SIGINT will be delivered also to
its parent process (and possibly other processes). The parent process then
will probably exit and mtest will continue running in the background, without
any way to interrupt the run completely.
To fix this, treat SIGINT and SIGTERM the same way unless mtest is a
process group leader.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The `except` line was missing its `as e` clause.
As a result, when erroring out, after not finding a compiler, Meson
gives an error ending:
```
File "C:\Users\Matthew\AppData\Roaming\Python\Python39\site-packages\mesonbuild\mesonlib\vsenv.py",
line 100, in setup_vsenv
mlog.warning('Failed to activate VS environment:', str(e))
```
Now, warnings are unconditionally raised when parsing the wrap file,
whether they are used or not. That being said, these warnings literally
just check for a couple of keys used in the .wrap ini file.
Moving these checks from the time of use to the time of loading, means
that we no longer report warnings only when originally downloading or
extracting the file or VCS repo.
It also means we no longer report warnings in one subproject, when a
wrap file is picked up from a different subproject because the first
subproject actually does a dependency lookup. This caused issues for the
WrapDB tooling, which uses patch_directory everywhere and the
superproject requires a suitable minimum version of meson for this...
but individual wraps might use a much lower version, and would then
raise a warning (in strict mode, converted to an error) when it resolved
a dependency from another WrapDB project.
Fixes#9118
Add 'formatoptions' to improve comment formatting.
Set b:match_words. See :help matchit
Set b:browsefilter. See :help browsefilter
Add 'expandtab' from the style guide and a meson_recommended_style
config variable to allow users to disable style-related settings. This
is a defacto standard feature for ftplugins.
This is broken and terrible and thus completely unusable. Don't torture
users by finding pkg-config on Windows, thus permitting the pkg-config
lookup of several dependencies that do not actually work -- which then
fails at build time.
This also breaks CI for the wrapdb, because Strawberry Perl is provided
as part of the base image for the OS (yes, even though it is terribly
broken!!!) and anything that depends on e.g. zlib will "find" zlib
because of this broken disaster, even though it should use the wrapdb
subproject of zlib.
It is assumed no one actually wants to mix Strawberry Perl and meson. In
fact, some projects, such as gst-build, already unconditionally error
out if Strawberry Perl is detected in PATH:
error('You have Strawberry Perl in PATH which is known to cause build issues with gst-build. Please remove it from PATH or uninstall it.')
Other projects (postgresql) actually do want to build perl extensions,
and link to the perl dlls, but absolutely under no circumstances ever
want to use its pkg-config implementation. ;)
Let's solve this problem by just considering this to not be a valid
pkg-config, let the user find another or not have one at all.
This change "solves"
https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues/11
There are a bunch of cases in a single function where we would want to
log the detected path of pkg-config. Formatting this is awkward. Define
it once, then use f-strings everywhere. :D
Eli Schwartz
Daniel Mensinger
Xavier Claessens
Thomas Heijligen
Jussi Pakkanen
Nirbheek Chauhan
Moroz Oleg
Dylan Baker
Hofer-Julian
Olexa Bilaniuk
Gabor Kertesz
Paolo Bonzini
Matthew Brett
Doug Kearns
Daniel Jacobs
Christian Clauss