| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
Fallout from the OptionStore refactor, and specifically commit
9a6fcd4d9a0c7bb248c5d0587632b741a3301e03. The `std` object was migrated
from having an option itself, to having the value fetched and saved
directly. In most cases, this also meant avoiding `.value`, but in a
couple cases this refactor went overlooked, and crashed at runtime.
Only affects Elbrus and Intel C++ compilers, seemingly.
Fixes #13401
|
|
For other reasons, Meson transforms "-Wno-x" into "-Wx -Wno-x" for GCC,
but this breaks with "-Wno-attributes=x" with:
```
cc1plus: error: arguments ignored for '-Wattributes='; use '-Wno-attributes=' instead
```
Suppress that workaround for -Wno-attributes=.
Closes: https://github.com/mesonbuild/meson/issues/13022
|
|
|
|
In 8d7ffe6e863834f0190e need_exe_wrapper() use was copied which was just reverted,
so replace with is_cross there too, to keep things in sync.
|
|
c1076241af11f10acac28d771688bb54c6b0b340 changed the logic in multiple
places, in particular it looks like it was assumed that is_cross is always
the same as need_exe_wrapper(), but that's not true.
Also the commit only talks about mypy, so this was definitely not intended.
This reverts all the cases where need_exe_wrapper() was introduced back to
is_cross.
The change in backends.py could be a correct simplification, but I don't know
the code base enough, so reverting that too.
See #13403 and #13410
|
|
The public facing name of language options is compiler option, so
let's standardise on that.
|
|
|
|
Fixes building Nasm objects with Meson's native language support, when
depending against a library that exports that flag, like Glib.
|
|
Which requires injecting some extra paths and the `-Xpreprocess` flag,
as well as extra search paths for libomp and the headers.
Fixes: #7435
|
|
And into the Clang-CL mixin.
|
|
This will be needed by the Apple compiler
|
|
|
|
_get_gnu_compiler_defines and _get_clang_compiler_defines were broken
by not defining the language they used.
Neither GCC nor Clang infer the language based on the driver name which means
`self.defines` isn't populated correctly in compilers/cpp.py.
e.g.
```
$ echo "" | g++ -E -dM - | grep -i cplus
$ echo "" | g++ -x c++ -E -dM - | grep -i cplus
#define __cplusplus 201703L
```
Fix that by passing '-cpp -x LANGUAGE' as a first pass. If it fails, try
again without '-cpp -x LANGUAGE' as before, as its portability isn't
certain. We do '-cpp' because during testing, I found Fortran needs this,
although per below, I had to drop Fortran in the end and leave it to the
fallback (existing) path.
Without this change, a63739d394dd77314270f5a46f79171a8c544e77 is only
partially effective. It works if the system has injected Clang options
via /etc/clang configuration files, but not by e.g. patching the driver
(or for GCC there too).
Unfortunately, we have to wimp out for Fortran and fallback to the
old method because you need the language standard (e.g. -x f95).
|
|
Make the debug & error message strings consistent between the GCC and Clang probes.
Copy-paste error. Here, we're scraping pre-processor tokens, not checking
for the compiler type.
|
|
|
|
There are two issues:
1. has_header() wants just the header name without surrounding <>
or similar; it fails otherwise.
2. has_header() returns a tuple of two bools, where the first element
determines whether or not the header has been found. So use
that element specifically, otherwise the tuple will always evaluate
to true because it is not empty.
Fixes: 675b47b0692131 ("compilers: cpp: improve libc++ vs libstdc++ detection (again)")
|
|
recognize the file extension `cppm` as c++ source file
|
|
Closes gh-13319
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Clang is such a great compiler! Not.
Compilers have enhanced diagnostics for some kinds of "well known"
undeclared identifiers, telling you exactly which header you might have
forgotten to include. The reason why clang needs an option GCC doesn't
need is because clang's fixit suggestions, unlike GCC's actually
*changes the type of the error*, as a result of a fixit of all things.
After the fixit suggestion grants this error the right to be ignored,
we start having to add clang-specific options.
Follow-up to https://github.com/mesonbuild/meson/issues/9140
Upstream clang bug, which appears to be going nowhere:
https://github.com/llvm/llvm-project/issues/33905
|
|
|
|
* Previously, cuda would just plainly prepend `-l` to the libname.
* By relying on the host compiler to find libraries, we now get
more subtle failures, such as CUDA modules not being found
anymore.
* We need to simplify these CUDA modules when nvcc is used for
linking, since this may have side-effects from the cuda toolchain.
Closes: #13240
|
|
|
|
|
|
Emscripten version numbers are unrelated to Clang version numbers,
so it is necessary to change the version checks for `c_std=c17` & co.
Without that, no project that defaults to C17 or newer will build with
Emscripten.
See https://github.com/pyodide/pyodide/discussions/4762 for more
context. Also note that this bug caused defaulting to C17 in
scikit-learn to be reverted (scikit-learn#29015), and it may be a
problem for SciPy 1.14.0 too since that release will upgrade from C99
to C17.
Co-authored-by: Loic Esteve <loic.esteve@ymail.com>
|
|
Basic support for TI Arm Clang toolchain
|
|
|
|
This is new as of 14.1.
|
|
Using the keyword argument dependencies with compiler.links() for vala doesn't work as the library being linked to needs to be prefixed with --pkg= before being passed to valac.
|
|
GCC only has very limited support for Objective-C and doesn't support
any of the modern features, so whenever Clang is available, it should be
used instead. Essentially, the only reason to ever use GCC for
Objective-C is that Clang simply does not support the target system.
|
|
Unlike in the Intel C compiler, -Werror and /WX are not accepted.
|
|
C#, Java, and Swift targets were manually collecting compiler arguments
rather than using the helper function for this purpose. This caused each
target type to add arguments in a different order, and to forget to add
some arguments respectively:
C#: /nologo, -warnaserror
Java: warning level (-nowarn, -Xlint:all, -Xdoclint:all), debug arguments
(-g, -g:none), -Werror
Swift: -warnings-as-errors
Fix this. Also fix up some no-longer-unused argument processing in the
Compiler implementations.
|
|
If nasm is not defined in cross file binaries we can fallback to build
machine nasm.
When cross compiling C code we need a different gcc binary for native
and cross targets, e.g. `gcc` and `x86_64-w64-mingw32-gcc`. But when
cross compiling NASM code the compiler is the same, it is the source
code that has to be made for the target platform. We can thus use nasm
from build machine's PATH to cross compile for Windows on Linux for
example. The difference is the arguments Meson will pass when invoking
nasm e.g. `-fwin64`. That is already handled by NasmCompiler class.
|
|
The user almost certainly has to be using a compiler wrapper script that
doesn't actually work if we land here.
Fixes: #12982
|
|
Fixes: #13100
|
|
Fixes issue #12959
compiler.links command for vala crashes
|
|
Fix ninja cannot find the library when libraries contain symlinks.
|
|
unsupported cl clones.
|
|
|
|
|
|
If -L flags get into CLikeCompiler::build_wrapper_args, they will be
correctly detected and the /LINK flag added to the list. However,
CompilerArgs::__iadd__ will reorder them to the front, thinking they're
GNU-style flags, and this will cause MSVC to ignore them after
conversion.
The fix is twofold:
1. Convert all the linker args into their compiler form, making sure the
/LINK argument is dropped (see 2)
2. Insert /LINK into extra_args if not already present
3. Execute in situ the unix_to_native replacement, ensuring no further
reordering occurs.
Fixes #11113
|
