Followup to 7b7d2e060b which handles ASAN and UBSAN.
It turns out that MSAN needs the same treatment. I've checked other sanitizers
like HWASAN and TSAN - it looks like they may both need it too, but Meson doesn't
currently suppose those anyway (see https://github.com/mesonbuild/meson/pull/12648).
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
This patch adds 'depends' keyword to compiler.preprocess().
It allows to execute other targets before doing the preprocessing.
Test-case is added to demonstrate that functionality: it
generates the header before preprocessing the C source that
uses that generated header.
Thanks to @bruchar1 for getting this patch to work.
For Clang, we now pass -D_GLIBCXX_DEBUG=1 if debugstl is enabled, and
we also pass -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_DEBUG.
Per https://discourse.llvm.org/t/building-a-program-with-d-libcpp-debug-1-against-a-libc-that-is-not-itself-built-with-that-define/59176/3,
we can't use _LIBCPP_DEBUG for older Clang versions as it's unreliable unless
libc++ was built with it.
We choose MODE_DEBUG for stldebug while building with assertions will do
MODE_EXTENSIVE.
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
None of the options set here affect ABI and are intended for detecting constraint
violations.
For GCC, we simply need to set -D_GLIBCXX_ASSERTIONS.
For Clang, the situation is far more complicated:
* LLVM 18 uses a 'hardened mode' (https://libcxx.llvm.org/Hardening.html).
There are several levels of severity available here. I've chosen
_LIBCPP_HARDENING_MODE_EXTENSIVE as the strongest-but-one. The strongest
one (_DEBUG) doesn't affect ABI still but is reserved for stldebug.
* LLVM 15 uses a similar approach to libstdc++ called '_LIBCPP_ENABLE_ASSERTIONS'
Note that LLVM 17 while in development had fully deprecated _LIBCPP_ENABLE_ASSERTIONS
in favour of hardened, but changed its mind last-minute: https://discourse.llvm.org/t/rfc-hardening-in-libc/73925/4.
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
This properly sets the project version in projects meson generates from
cmake projects. This allows dependency fallbacks to properly check the
version constraints in dependency calls when falling back to a cmake
subproject. Before this would fail, because the project version was
undefined.
This is needed now that str.format() is not allowing it any more. It is
also more consistent with other objects that have that method as well,
such as build targets.
Fixes: #12406
It was previously impossible to do this:
```
dep.get_pkgconfig_variable(
'foo',
define_variable: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
since get_pkgconfig_variable mandated exactly two (if any) arguments.
However, you could do this:
```
dep.get_variable(
'foo',
pkgconfig_define: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
It would silently do the wrong thing, by defining "prefix" as
`/usr=datadir=/usr/share`, which might not "matter" if only datadir was
used in the "foo" variable as the unmodified value might be adequate.
The actual intention of anyone writing such a meson.build is that they
aren't sure whether the .pc file uses ${prefix} or ${datadir} (or which
one gets used, might have changed between versions of that .pc file,
even).
A recent refactor made this into a hard error, which broke some projects
that were doing this and inadvertently depending on some .pc file that
only used the second variable. (This was "fine" since the result was
essentially meaningful, and even resulted in behavior identical to the
intended behavior if both projects were installed into the same prefix
-- in which case there's nothing to remap.)
Re-allow this. There are two ways we could re-allow this:
- ignore it with a warning
- add a new feature to allow actually doing this
Since the use case which triggered this bug actually has a pretty good
reason to want to do this, it makes sense to add the new feature.
Fixes https://bugs.gentoo.org/916576
Fixes https://github.com/containers/bubblewrap/issues/609
When a user invokes the scan-build target that Meson generates
all subprojects are included in the resulting report. This commit
modifies the invocation of scan-build to exclude all bugs that
scan-build finds in the subprojects from the final report.
A release note has also been added describing the changed behaviour.
Do as we do for MALLOC_PERTURB and set a sensible value for both ASAN_OPTIONS
and UBSAN_OPTIONS to abort on failure and give more helpful output at the
same time. We do not set these options if the user has exported a value
themselves to allow override.
In the last week alone, I've observed two cases where people were expecting
sanitizers to abort on failure and were surprised when it didn't:
1) 252d693797
2) c47df433f7
Correct this - which is in-line with meson's DWIM/DTRT philosophy.
Signed-off-by: Sam James <sam@gentoo.org>
Which allow passing arguments specifically to the static or shared
libraries.
For design, this is all handled in the interpreter, by the build layer
the arguments are combined into the existing fields. This limits changes
required in the mid and backend layers
Since the previous commit allows for more scenarios with name
collisions, it makes sense to expand the compile command so that it can
also take into account suffixes. i.e. meson compile -C build foo.exe can
now work if the executable has an exe suffix along with being named foo.
When checking target names, meson explictly forbids having multiple
targets with the same name. This is good, but it is strict and it is
impossible to have targets with the same basename and differing suffixes
(e.g. foo and foo.bin) in the same directory. Allow this for executables
by including the suffix (if it exists) in the interal target id. So foo
would be foo@exe and foo.bin would be foo.bin@exe.
Add the `clang-tidy-fix` target to apply clang-tidy fixes to the source
code.
This is done by calling `run-clang-tidy` with `-fix` argument.
Add a test case to run `clang-tidy-fix` and verify the file is changed.
Signed-off-by: Lei YU <yulei.sh@bytedance.com>
The method can be overridden by setting the `method` key in the wrap
file and always defaults to 'meson'. cmake.subproject() is still needed
in case specific cmake options need to be passed.
This also makes it easier to extend to other methods in the future e.g.
cargo.
Allow macro_name to be speficied as a parameter to configure_file().
This allows C macro-style include guards to be added to
configure_file()'s output when a template file is not given. This change
simplifies the creation of configure files that define macros with
dynamic names and want the C-style include guards.
A standard C library may not exist for cross-compile
environments, thus the existence of <stdio.h> cannot be
guaranteed.
Use <stddef.h> instead, this header contains compiler-specific
defines thus it usually comes from the compiler.
Adds a new method to the compiler object, has_define.
This makes it possible to check if a preprocessor macro/define
is set or not.
This is especially helpful if the define in question is empty,
for example:
#define MESON_EMPTY_DEFINE
This would yield the same results as a missing define with
the existing get_define method, as it would return an empty
string for both cases. Therefore this additional method is
needed.
Allow packagecache to contain already extracted directory to match what
some distro does with Cargo source packages in /usr/share/cargo/registry.
Note that there is no need to lock the cache directory because we
download into a temporary name and atomically rename afterward. It means
we could be downloading the same file twice, but at least integrity is
guaranteed.
Fixes: #12211
`meson setup -Dfoo=bar builddir` command was returning success ignoring
new option values.
This now also update options. It is useful because it means
`meson setup -Dfoo=bar builddir && ninja -C builddir` works regardless
whether builddir already exists or not, and when done in a script,
changing options in the script will automatically trigger a reconfigure
if needed. This was already possible by always passing --reconfigure
argument, but that triggers a reconfigure even when options did not
change.
This reverts commit f52bcaa27f.
It did not pass CI, and was merged anyway because there were two CI
errors in the same cygwin job. The other error was not the fault of this
commit, and since cygwin errors were glossed over because they were
"expected", the presence of a new error *added* by this commit was
overlooked.
Per the meson development policy, PRs which result in CI errors
can/should be reverted at will, no questions asked.
This commit adds a new keyword arg to extension_module() that enables
a user to target the Python Limited API, declaring the version of the
limited API that they wish to target.
Two new unittests have been added to test this functionality.
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.
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>
Charles Brunet