This is in preparation for a future commit which makes it
possible for a PythonPkgConfigDependency to be used in a
context where previously only a PythonSystemDependency would
be used.
Instead of invoking javac for every .java file, pass all of the sources
for a jar target to a single javac invocation. This massively improves
first compilation time and doesn't meaningfully affect incremental builds
(it can even be faster in some cases).
The old approach also had issues where files would not always get recompiled
even though they should, necessitating a clean rebuild in order to see changes
reflected in the build output.
Multiple invocations seem to only make sense if:
- issues with files not getting flagged for rebuild are investigated and fixed
- something like the javaserver buildtool from openjdk sources is used
instead of directly spawning javac processes
- the amount of java files per jar is so large that it is faster to compile
several files one by one than to compile all the files at once (batching may
still make sense to get a reasonable balance)
From python 3.11 [1]:
> The entry in the netrc file no longer needs to contain all tokens. The missing
> tokens' value default to an empty string. All the tokens and their values now
> can contain arbitrary characters, like whitespace and non-ASCII characters.
> If the login name is anonymous, it won't trigger the security check.
[1] 15409c720b
Some settings require "objectVersion" to be set to a certain value or
Xcode will not use it. To fix this, we set it to the highest possible
value, determined by the detected version of Xcode. We also set
"compatibilityVersion", but mainly so it lines up with "objectVersion".
At the same time, we should not be generating Xcode 3.2-compatible
projects by default anyway.
`configure_file` kwarg `copy` runs at configure time, whereas
`fs.copyfile` runs at build time. Both have use cases, so this
undeprecates the `configure_file` version.
Fixes: #12792
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
This reverts commit aee941559c.
The commit being reverted breaks compilation of a major Meson consumer
(Mesa). As a result, various distros are either pinning to <1.4.0 (before
the commit) or performing this same revert downstream.
Fixing a regression takes priority, so let's revert.
Fixes: https://github.com/mesonbuild/meson/issues/12973
* 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
We do:
```
if is_thing:
assignme = value
if_is_thing:
...
else:
assignme = []
```
It is always defined on both sides, but there was no particular reason
we had to assign it in the later copy. pylint reported it as a false
positive, and it may prove confusing in general, and it's harmless to
move, so do so.
We cover every case as if/elif/elif. mypy can handle this fine, but
pylint doesn't do control flow or type checking and thinks in the
missing else case, the variable might not be defined.
For mypy as well, doing this instance check is unnecessary as it can be
inferred. So just micro-optimize the check and allow pylint to safely
analyze the logic.
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>
When running our integration tests in systemd we depend on each test
having a unique name. This is always the case unless --repeat is used,
in which case multiple tests with the same name run concurrently which
causes issues when allocating resources that use the test name as the
identifier.
Let's set MESON_TEST_ITERATION to the current iteration of the test so
we can use $TEST_NAME-$TEST_ITERATION as our test identifiers which will
avoid these issues.
* In `CudaDependency._detect_language`, the first detected language is
considered the linking one. Since `nvcc`/`cuda` implicitly know where the
cuda dependency lives, this leads to situations where `cpp` as linking
language is erroneously detected as `cuda` and then misses the `-L` argument.
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.
This uses objfw-config to get to the flags, however, there's still
several todos that can only be addressed once dependencies can have
per-language flags.
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.
Running `touch` on a tracked file in Git, to update its timestamp, and
then running `meson dist` would cause dist to fail:
ERROR: Repository has uncommitted changes that will not be included in the dist tarball
Use --allow-dirty to ignore the warning and proceed anyway
Unlike `git status` and `git diff`, `git diff-index` doesn't refresh the
index before comparing, so stat changes are assumed to imply content
changes. Run `git update-index -q --refresh` first to refresh the index.
Fixes: #12985
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 docs didn't really explain what the issue was with using it. And
it's not actually a "crash" either way.
The FeatureNew mentions that "name" is new, but it is standard for
these warnings to tell you both the type of object you're operating on
and the name of the method that is an issue. This omitted the former,
and was very confusing.
Andrew McNulty
Mis012
Jussi Pakkanen
Ruben Gonzalez
Wolfgang Walther
Albert Tang
Filipe Laíns
David Seifert
Marc Durdin
Eli Schwartz
Sam James
Axel Ricard
Ralf Gommers
Stas Sergeev
Daan De Meyer
Tristan Partin
matyalatte
Ben Corby
kkz
Jonathan Schleifer
Benjamin Gilbert
Xavier Claessens