clang has supported gcc syntax since version 3.3.0 from 10 years ago.
It's better than its own version because it takes a "when" verb which
allows us to explicitely ask for "auto". This is useful when overriding
flags that came from elsewhere.
Before this patch, meson was just treating b_colorout="auto" as "always".
Since CPython 3.8 .pyd files no longer look in PATH for loading libraries,
but require the DLL directory to be explicitely added via os.add_dll_directory().
This resulted in those tests failing with 3.8+ on Windows.
Add the DLL build directory with os.add_dll_directory() to fix them.
This was never noticed in CI because it only uses Python 3.7 and the
MSYS2 CPython still used the old behaviour until now.
meson tests enable PYTHONWARNDEFAULTENCODING by default and
make EncodingWarning fatal too.
Starting with Python 3.11 CPython not only warns if no encoding is passed
to open() but also to things like subprocess.check_output(). This made
the call in vsenv.py fail and in turn made test_vsenv_option fail.
check_output() here calls a .bat file which in turn calls vcvars. I don't
know what the encoding is supposed to be used there, so just be explicit
with the locale encoding to silence the warning.
When an installed static library A links to an internal static library B
built using a custom_target(), raise an error instead of a warning. This
is because to be usable, A needs to contain B which would require to
extract the archive to get its objects files.
This used to work, but was printing a warning and was installing a
broken static library, because we used to overlink in many cases, and
that got fixed in Meson 1.2.0. It now fails at link time with symbols
from the custom target not being defined. It's better to turn the
warning into a hard error at configure time.
While at it, noticed this situation can happen for any internal custom
or rust target we link to, recursively.
get_internal_static_libraries_recurse() could be called on CustomTarget
objects which do not implement it, and even if we did not call that
method, it would still fail when trying to call extract_all_objects() on
it.
Fixes: #12006
Projects that prefer GNU C but can fallback to ISO C can now set for
example `default_options: 'c_std=gnu11,c11'` and it will use gnu11 when
available, fallback to c11 otherwise. It is an error only if none of the
values are supported by the current compiler.
This allows to deprecate gnuXX values from MSVC compiler, that means
that `default_options: 'c_std=gnu11'` will now print warning with MSVC
but still fallback to 'c11' value. No warning is printed if at least one
of the values is valid, i.e. `default_options: 'c_std=gnu11,c11'`.
In the future that deprecation warning will become an hard error because
`c_std=gnu11` should mean GNU is required, for projects that cannot be
built with MSVC for example.
Improve the error message when a build target is assigned as dependency
of another build target, which allows to better pinpoint where the issue
lies on.
In the example that follow, modules/meson.build:294 is in a for loop
creating library targets from an array of dictionary, and doesn't point
to the location where interop_sw_plugin is assigned with vlc_opengl:
Before:
modules/meson.build:294:17: ERROR: Tried to use a build target as a dependency.
You probably should put it in link_with instead.
After:
modules/meson.build:294:17: ERROR: Tried to use a build target vlc_opengl as a dependency of target interop_sw_plugin.
You probably should put it in link_with instead.
It would probably be best to directly pinpoint where the assignment was
made but it's probably harder so start simple by saying what is
concerned by the error.
If we have a build- or host-architecture compiler, we can detect mips64
vs. mips by the fact that mips64 compilers define __mips64. However,
machine_info_can_run() doesn't provide any compilers, because it is
interested in the architecture of the underlying kernel. If we don't
return mips64 when running on a mips64 kernel, machine_info_can_run()
will wrongly say that we can't run mips64 binaries.
If we're running a complete 32-bit mips user-space on a mips64 kernel,
it's OK to return mips64 in the absence of any compilers, as a result
of the previous commit "environment: Assume that mips64 can run 32-bit
mips binaries".
Resolves: https://github.com/mesonbuild/meson/issues/12017
Bug-Debian: https://bugs.debian.org/1041499
Fixes: 6def03c7 "detect_cpu: Fix mips32 detection on mips64"
Signed-off-by: Simon McVittie <smcv@debian.org>
The relationship between mips64 and mips is similar to the relationship
between x86_64 and x86. Representing it here is necessary so that we
will not require an exe_wrapper when cross-compiling for 32-bit mips on
mips64, or when a complete 32-bit mips user-space runs on a 64-bit kernel
without using linux32 to alter uname(2) to pretend to be 32-bit.
Signed-off-by: Simon McVittie <smcv@debian.org>
In some cases the desired result can be different if there are no
compilers at all. The expectations here are based on there being at
least one compiler, so reflect that by providing one; a later test
enhancement can cover the case where there are no compilers provided.
As a result of the mock any_compiler_has_define(), all that matters
will be the distinction between an empty or non-empty dict: the compiler
object itself is unused.
Signed-off-by: Simon McVittie <smcv@debian.org>
add the "required" keyword to the functions
has_function
has_type
has_member
has_members
has_argument
has_multi_arguments
has_link_argument
has_multi_link_argument
has_function_attribute
Co-authored-by: Milan Hauth <milahu@gmail.com>
We support this in a machine file:
```
[binaries]
pkgconfig = 'pkg-config'
pkg-config = 'pkg-config'
```
and you can use either one, because internally we look up both. If you
only set *one* of them, this plays awkwardly with setting $PKG_CONFIG,
since we don't know which one you set in the machine file and the
*other* one will be initialized from the environment instead.
In commit 22df45a319 we changed program
lookup of config-tool style dependencies to use the regular tool names
and only fall back on the strange internal names. This affected the
pkg-config class too.
The result is that instead of preferring `pkgconfig =` followed by
$PKG_CONFIG followed by `pkg-config =`, we inverted the lookup order.
This is a good idea anyway, because now it behaves consistently with
`find_program('pkg-config')`.
Unfortunately, we documented the wrong name in a bunch of places, and
also used the wrong name in various testsuite bits, which meant that if
you set $PKG_CONFIG and then ran the testsuite, it would fail.
Correct these references, because they are buggy.
One test case expected to find_program() a native copy for convenience
of testing against natively installed glib. Force it to resolve a native
copy.
On my project, this function was a bottleneck in setup time.
By properly caching it, the cumtime for this function
went from 26s to 4.3s when I profiled it.
By default, pdb assumes that any command run is python code to be
evaluated, but only if that code isn't a builtin pdb command. You can
force it to be evaluated as python code by prefixing it with `!`.
It's handy to simply name a python variable and have its variable be
printed.
But single letter variables like 's' and 'p' make debugging with pdb
commands (i.e. 's'tep, and 'p'rint evaluated expressions) less
convenient, and potentially confusing.
When performing isinstance checks, an identity comparison is
automatically done, but we don't use isinstance here because we need
strict identity equality *without allowing subtypes*.
Comparing type() == type() is a value comparison, but could produce
effectively the same results as an identity comparison, usually, despite
being semantically off. pycodestyle learned to detect this and warn you
to do strict identity comparison.
We allow custom_target() but check for it based on hasattr, ever since
the initial implementation way back in the day, in commit
66a6ea984b. This is a bit broken because
various objects might support that but still aren't supposed to work. We
can actually just use isintance checks like we do immediately above,
which are more accurate and avoid crashes on things that aren't even
targets at all, like run_target(). Although custom_target indexes are
actually targets those didn't work either.
Fixes#9648
For some (atm unknown) reason mingw Python fails to load some modules
when MSYS2 is removed from PATH, like in this test.
Skip for now to make the test suite pass again. Once
https://github.com/msys2-contrib/cpython-mingw/issues/141 is fixed
this can be reverted.
The wording was a bit confusing and misled at least one person into
thinking it behaved like `str.replace('c', '')` operating on the entire
line. Tweak the wording to be more precise and avoid this confusion.
This fixes two issues in constructing the default installation path
when install_dir is not specified:
- inside a subproject, install_data() would construct the destination
path using the parent project name instead than the current project
name,
- when specifying preserve_path, install_data() would construct the
destination path omitting the project name.
Fixes#11910.
The function name adheres to the pattern used by many other Meson DSL
implementation methods, thus stating that this is the implementation
of the functionality without argument validation is not very useful.
The docstring is separated from the function declaration by a blank
line. Removing the docstring avoids having to decide if the blank line
should be there or not.
kiwixz
Christoph Reiter
Dylan Baker
Lucas Alber
Xavier Claessens
Sebastian Crane
Alexandre Janniaux
Simon McVittie
Milan Hauth
Nomura
Eli Schwartz
Volker Weißmann
Charles Brunet
Alex Rao
Jussi Pakkanen
Dan Hawson
Daniele Nicolodi