Previously, AIX support was updated to archive shared libraries per AIX
platform conventions, which expect .a files that contain .so files. This
is usually correct, but an edge case occurs for loadable plugins, e.g.
what meson creates for `shared_module()`. A notable example is python
extensions (SciPy, for example).
These should *not* be archived, because the .so file itself needs to be
loaded as a plugin. For example, SciPy fails to import in the python
interpreter.
Handle this by differentiating between plugins and regular libraries,
and only archiving when safe to do so.
Fixes#12219
Previously, creating a meson wrap with "method=cargo"
for https://github.com/sunfishcode/is-terminal would fail,
because its Cargo.toml contains a [target] section without
dependencies.
Instead, we now fall back to an empty list in case of no specified dependencies
(like everywhere else in "_convert_manifest")
Regression in commit a3d287c553.
When a given kwarg is not specified, we want to not generate it as a
simd variant. Since the default for buildtarget sources is `[]` it
resulted in building a static library with no sources, and a warning
stating that this was buggy and will eventually be removed.
Fix this by teaching buildtarget sources to allow None, and defaulting
to it specifically for the simd module. We can check this and then skip
processing entirely.
Fixes#12438
Certain envs may not support invoking itstool by itself directly as a script
as shebang lines are not supported, such as under cmd.exe shells on Windows,
that are normally used for Visual Studio (and the like, such as clang-cl)
builds.
This will call the corresponding interpreter to invoke itstool when needed, so
that itstool can be properly run, even if shebang lines are not supported by
the env.
This will fix building appstream on Windows using clang-cl, for instance.
adb1a360b9 added the feature and also the
usual meson-style warning to users that might be using the feature but
were not targeting a new enough meson version. Well unfortunately the
warning both doesn't actually work (it didn't take different directories
into account) and is also really slow because it creates an O(N^2) loop
for checking this.
Instead, rework this by adding an additional set that stores a tuple
containing the target name and its subdirectory. We only add this tuple
if the target is an executable since it is the only time it will be
relevant. After that, simply check if the name + subdir combination
already exists in the set along with the target being executable. If so,
then we execute FeatureNew which may possibly warn. This is a simply
O(1) lookup which is way faster. Fixes#12404.
Partially reverts commit 1624354f33 which
moved a bunch of stuff from strings to enums. The issue here is that
Compiler.mode is not just, or primarily, something we compare, but is
instead written in as e.g. `rule c_{compiler.mode}` to build.ninja, so
this identifier needs to be a string.
Ultimately, the issue is that the commit tried to rewrite a bunch of
things called "mode" that had a couple of TODOs saying to use enums...
but it rewrote everything called "mode" regardless of whether it was a
function kwarg or a compiler property, even though the TODO only applied
to one of them.
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>
The DCompiler and DmDLikeCompiler classes both implement the exact same
`get_feature_args()` method. The DmdLikeCompiler inherits the DCompiler.
As such, removing it doesn't change the behavior of anything, but
decreases the chances of bugs being introduced, as well as LoC.
The <lang>_stdlib can be used in cross files to use a custom standard library
for a given language.
When cpp_stdlib is used in a cross file, meson passes
* -nostdinc++ to the compiler
* -nostlib to the linker
According to [1] (gcc) and [2] (clang), we should pass -nostlib++ to the linker
when we don't want to link to the standard C++ library.
Currently, we pass -nostlib.
Fix this by implementing a C++ specific get_no_stdlib_link_args() function.
[1] https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#index-nostdlib_002b_002b
[2] https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-nostdlib
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
The MSVC linker errors out if a line in the rspfile is too long.
The resolution is to use the built-in ninja keyword $in_newline instead of $in, which splits each input into separate lines.
A rebase of the current branch is the wrong thing to do if the
revision (branch) specified in the wrap changed, which is the case in
the majority of cases, such as when switching from one release branch
to another.
Don't leave the subproject tree in a broken / conflicting state. The
user is most likely not a git expert who will know what magic command
to run to fix their source tree.
Aditya Vidyadhar Kamath
Luke Elliott
Alaska
Eli Schwartz
Jussi Pakkanen
Chun-wei Fan
Dudemanguy
Eli Schwartz
Tristan Partin
Dylan Baker
Xavier Claessens
Sam James
Nirbheek Chauhan
Mattijs Korpershoek
Ada
Charles Brunet