| Age | Commit message (Collapse) | Author |
|---|
|
Rust edition 2024 is being released in February, add support for rust_std=2024.
Resolves: #14074
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This adds --cap-lints allow, matching how Cargo builds them. In the case of
Cargo, this is only applied to non-path dependencies.
Without this change, clippy will complain about dependencies as well.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This is a better and more backwards-compatible way to disable all warnings,
compared to "-A warnings". The Rust RFC (https://rust-lang.github.io/rfcs/1193-cap-lints.html)
explains the rationale:
> We would very much like to be able to modify lints, however. For example
> rust-lang/rust#26473 updated the missing_docs lint to also look for missing
> documentation on const items. This ended up breaking some crates in the
> ecosystem due to their usage of #![deny(missing_docs)].
While at it, document that Rust deviates from the other languages in its
interpretation of warning_level=0.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
When running `ninja all` we shouldn't build testsuite programs as these
might not be wanted e.g. in order to just install the project. We do
want them to be built when running `ninja test`. Since meson 0.63 we
actually have a dedicated ninja alias for test dependencies -- move
these from the "all" rule to the dedicated test/benchmark rules.
Closes: https://github.com/mesonbuild/meson/issues/1704
Closes: https://github.com/mesonbuild/meson/issues/1949
Closes: https://github.com/mesonbuild/meson/issues/2518
Closes: https://github.com/mesonbuild/meson/issues/3662
Closes: https://github.com/mesonbuild/meson/pull/5728
Closes: https://github.com/mesonbuild/meson/pull/5867
Closes: https://github.com/mesonbuild/meson/pull/6511
Closes: https://github.com/mesonbuild/meson/pull/11317
Closes: https://github.com/mesonbuild/meson/issues/13378
|
|
|
|
|
|
|
|
|
|
|
|
Almost exactly the same as how the dl dependency works. On certain
systems (like BSDs that use clang), stdatomic is provided by compiler-rt
and doesn't need a separate library explictly linked. On a typical
GNU/LINUX system, atomic is a separate library that must be explictly
found and linked against. So just add a builtin and system method for
these two use cases.
|
|
clippy-driver is not meant to be a general-purpose compiler front-end.
Since Meson can now provide natively the ability to invoke clippy,
raise a warning if someone uses it that way.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Add a target that builds all crates that could be extern to others,
and then reruns clippy.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This improves the handling of keyboard interrupt, and also makes it easy to
buffer the output and not mix errors from different subprocesses. This
is useful for clang-tidy and will be used by clippy as well. In addition,
the new code supports MESON_NUM_PROCESSES.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Even though the "targets" introspection info already includes the
command line arguments used to invoke the compiler, this is not
enough to correlated with the "compilers" introspection info and
get extra information from there.
Together with the existing "language" key, adding a "machine" key
is enough to identify completely an entry in the compilers info.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
It is useful to apply a limit to the number of processes even outside "meson test",
and specifically for clang tools. In preparation for this, generalize
determine_worker_count() to accept a variable MESON_NUM_PROCESSES instead of
MESON_TESTTHREADS, and use it throughout instead of multiprocessing.cpu_count().
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Fixes #13791
|
|
Makes all entries consistent
|
|
There is actually very little overlap between `install_sources` and
`install_data` in arguments they accept: only 2/7 keywords for `install_data`
apply to `install_sources`.
Closes gh-12601
|
|
|
|
They recently made the switch from Autotools to Meson
|
|
|
|
Fixes: #4893
|
|
Document the results of commit bcc127b3f,
which added 'depends' and deprecated using
'dependencies' for custom targets.
Fixes: #11479
|
|
Meson allows to set the archiver via the `AR` environment variable and a
native / cross file. Only the latter approach seems to be documented.
This patch adds the `AR` environment variable to the reference tables
next to the compilers.
|
|
The quick example can be slightly misleading in implying that scan_xml
must use find_protocol, which is not the case. So explicitly mention it
in the scan_xml docs.
|
|
python.install_env is the correct command, as documented
in https://mesonbuild.com/Builtin-options.html#python-module.
python.install_venv causes an error, it is not immediately obvious
that the slight typo is the cause.
|
|
|
|
The output_is_64bit, sizeof, cross_sizeof, compute_int and cross_compute_int
methods are reimplemented for Fortran compilers. Those inherited from
CLikeCompiler do not work since they assume C or C++.
Note that those tests rely on Fortran 2008 features (notably the c_sizeof
operator).
Closes #12757
|
|
Introduce a global Cargo interpreter state that keeps track of enabled
features on each crate.
Before generating AST of a Cargo subproject, it downloads every
sub-subproject and resolves the set of features enabled on each of them
recursively. When it later generates AST for one its dependencies, its
set of features and dependencies is already determined.
|
|
|
|
|
|
uname -s does return gnu there.
Resolves: https://github.com/mesonbuild/meson/issues/13740
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
|
|
|
|
Closes: #13773.
|
|
|
|
fixes #13271
|
|
|
|
As the 2018 standard changes the way rust handles externs, and is the
first edition that allows `--extern crate=path` to completely replace
(in all but a few corner cases) the use of `extern crate` in the rust
files.
|
|
Which were added in Meson 1.2, but don't have entires in the reference
manual.
|
|
Previously, the documentation said that the CPU name might be amd64,
but in fact x86_64 (AMD64) machines are detected as x86_64 in both
cpu() and cpu_family() during native builds. Reference:
https://buildd.debian.org/status/fetch.php?pkg=libglvnd&arch=amd64&ver=1.7.0-1%2Bb1&stamp=1714222481&raw=0
Instead, mention the only common case for more-specific CPU names
other than 32-bit x86, namely 32-bit ARM. On Debian's autobuilders
(which are running 32-bit user-space on a 64-bit-capable CPU),
native builds genuinely do present as `armv8l`:
https://buildd.debian.org/status/fetch.php?pkg=libglvnd&arch=armhf&ver=1.7.0-1%2Bb1&stamp=1714223924&raw=0
On other machines, they might be some older CPU functionality level.
At the time of writing, cpu() *can* return amd64 when using
`meson env2mfile` on Debian systems, but I think that's a bug in
env2mfile (#13742).
Signed-off-by: Simon McVittie <smcv@debian.org>
|
|
|
|
For many years now, meson hasn't required manually entering a Visual
Studio command prompt but has autodetected it. This confuses some
readers of this outdated documentation into thinking it is much harder
than it is.
|
|
|
|
This allows checking for tools that may not be available in older version of qt
or avoiding requesting tools that may not be necessary for a given project
Co-authored-by: Nirbheek Chauhan <nirbheek@centricular.com>
|
|
|
|
|
|
|
|
|
|
These errors can make reading comments and documentation
unnecessarily confusing for users and contributors who
do not speak English as their first language.
|
