Both recvmmsg/sendmmsg and statx require the `_GNU_SOURCE` symbol to be
defined to be shown in headers, but statx has the additional property of
being defined on all glibc systems[1], unlike recvmmsg which isn't
implemented on Hurd[2][3].
With this fix, all tests now pass on Hurd.
$ cat meson.build
project('test', 'c')
cc = meson.get_compiler('c')
cc.has_header_symbol('sys/stat.h', 'statx')
cc.has_header_symbol('sys/stat.h', 'statx', prefix: '#define _GNU_SOURCE')
cc.has_function('statx')
$ meson setup build
The Meson build system
Version: 1.5.1
Source dir: /tmp/tmp.XcWk4fMra4
Build dir: /tmp/tmp.XcWk4fMra4/build
Build type: native build
Project name: test
Project version: undefined
C compiler for the host machine: cc (gcc 14.2.0 "cc (Debian 14.2.0-3) 14.2.0")
C linker for the host machine: cc ld.bfd 2.43.1
Host machine cpu family: x86_64
Host machine cpu: x86_64
Header "sys/stat.h" has symbol "statx" : NO
Header "sys/stat.h" has symbol "statx" : YES
Checking for function "statx" : YES
Build targets in project: 0
[1]: https://sourceware.org/git/?p=glibc.git;a=blob;f=io/statx_generic.c;h=93faf12297cfcd37ba005a02e991eab351d74174;hb=HEAD
[2]: https://www.gnu.org/software/hurd/open_issues/glibc.html#recvmmsg
[3]: https://github.com/mesonbuild/meson/pull/4351
When we're using the output of configure_file() with
override_find_program(), we weren't storing the version anywhere, so
get_version() was trying to run the script during setup.
This is usually fine, except in cases where the configure_file()
script actually has to import a library built as part of the project,
and fails to run.
For built executables, we simply use the project version, and we
now do the same here too.
Clang's resource files, e.g. /usr/share/clang/clang++.cfg, can be used to bump the default standard level across the system.
However due to llvm/llvm-project#61641 `clang++ -std=c++17 -E -dM -` doesn't work. The workaround is to pass the language explicitly.
4ad792e158 fixed the issue by passing the language explicitly, but started passing the `-cpp` flag, which Clang doesn't support.
Basically Clang would always fallback to the second detection attempt as a result. Remove the unsupported flag and the above scenarios works now too. 🙂
See-also: https://github.com/llvm/llvm-project/issues/61641
Fixes: 4ad792e158
The "on" option is documented as passing the warning flags to all
subtools, and implies "most".
The default in the majority of projects is -warnings on,nocmdline, which
I'd take to be the equivalent of -Wall -Wextra, there isn't really an
inbetween.
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.
Sanity check for bare metal rust wasn't working for a while and there is a pending PR (#12175).
To workaround this problem, we used to let sanity check for build machine and manually defined
rustc target.
Commit 18f8aeda8b breaks this workaround as, even without an
exe_wrapper, native_static_libs are appends as internal deps.
This behaviour makes sense for cross compiled rust in a rich environment but not any for
no-std rust. As said in comments, one can't tell if the code is no-std or not because this is
an annotation from sources. From our point of view, it is pretty clear that building a no-std
rust target means that one has to define system='bare metal' and kernel='none' in his cross-file.
According to that, sanity_check for rust compiler is modified to handle kernel == 'none' case
by building a specific no-std rust snippet, with an extra args if rust_ld is ls.bfd (in order
to prevent the linker to link with a potentially non existing startfile for the given target).
'native_static_libs' is also leave empty in that very case.
This commit fix the spurious native static libs for no-std case and allow us to remove
our dirty workaround which by-passed non working sanity check for bare metal rust.
One who wants to use meson for baremetal Rust project only have to define the rust target
in their cross file.
e.g.
rust = ['rustc', '--target', '<rustc valid target>']
The clang-tidy-fix target uses run-clang-tidy to do the fixing, however
this script itself spawns `os.cpu_count()` threads as part of its
internal parallelism. When combined with Meson's parallelism this
results in the creation of potentially thousands of unecessary threads.
This commit rewrites the clang-tidy-fix to perform the same task
run-clang-tidy does but exclusively on Meson's thread pool. "Fix-it"
snippets are saved to `meson-private/clang-tidy-fix/` by a parallel
clang-tidy phase, afterwards (to avoid races) all collected fixes are
applied with a single call to clang-apply-replacements.
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>
The standard way to compile MPI applications (recommanded by all MPI implementations)
is to use the commands mpicc/mpiicc (and friends). Therefore, it is standard to
just set PATH such that mpicc points towards a wrapper of the MPI implementation
that one wants to use.
In contrast, pkg-config is supported only by OpenMPI.
Therefore, Meson has first to take into account the mpicc command to get chance
to use mpicc of MPICH or IntelMPI in the case OpenMPI is installed
(so that pkg-config would find it).
Otherwise internal dependencies have auto-generated names that are not
human readable. Instead, use the name that the dependency overrides. For
example:
```meson
meson.override_dependency('zlib', declare_dependency())
dep_zlib = dependency('zlib')
assert(dep_zlib.name() == 'zlib')
```
Fixes: #12967
When a dependency is copied and its name is changed, we still need a way
to say "this is the same dependency", which we now have. It is
important, however, when a partial dependency is created that dependency
does *not* match the original dependency, since they are not providing
the same data. This was always happening for InternalDependencies as an
implementation detail, but not for other kinds.
The D compiler and associated tools are installed under /root and the
setup script run during the actual testing expects that `~` will
expand to the same path. Because github overrides HOME the dmd
environment setup script will not be run which leads to all D related
tests being skipped, even though the whole test suite reports as
having finished successfully.
Signed-off-by: Andrei Horodniceanu <a.horodniceanu@proton.me>
The common test case "268 install functions and follow symlinks"
requires that certain symlinks exist in order to function.
If one clones a fresh repo and executes run_single_test.py with
the aforementioned test as the target it will fail as the required
symlinks are not part of the repo.
Normally these symlinks are created and cleaned up when the
overall testsuite is run but this is not the case for
run_single_test.py
This commit calls the necessary creation and cleanup functions
in the case of run_single_test.py.
When running in some settings, a C compiler may demand newlines at the
end of each file. Instead of modifying everywhere that writes out test
files to incorporate newlines in each indivudual string, simply add a
newline when writing it out.
Only add a newline to the end of the file if there isn't one already
there.
An examples of when this is a problem is running with `CC=clang` and
`CFLAGS="--std=c99 -pedantic-errors"` and meson.build contains (for
example) the following:
```
project('myproject', 'c')
executable('myexecutable', 'main.c')
cc = meson.get_compiler('c')
sizeof_int = cc.sizeof('int')
```
sizeof_int will be -1, because the compile failed. The meson logs
contain the error `testfile.c:7:10: error: no newline at end of file`
The x86 test files might not work on x86_64 Linux in certain cases,
for example if the kernel is configured without support for x86
executables (which also gets rid of the old system call interface).
Bug: https://bugs.gentoo.org/936911
It is genuinely horribly buggy so we don't want the testsuite to
succeed. We make a special exception for the CI runner since it is a
known breakage but people packaging meson should see the issue.
https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html
GNU Gettext defines a feature, whereby for translation purposes, if
LC_ALL / LANG are *not* set to C, but rather define an active
translation, the LANGUAGE variable can be used to specify fallback
languages in a colon-separated list wherein the first option is the
primary language and the rest are fallbacks.
CPython, instead, checks the LANGUAGE variable first, and the first
variable that has a non-null value is treated as the canonical language
specification, splitted, and iterated over. LC_ALL=C is therefore
totally ignored, which is a major problem, and the variables aren't
checked for consistency, which is a less major problem.
GNU libc documents the same behavior CPython does -- which is broken as
it makes LC_ALL=C useless.
POSIX issue 8 standardizes on option 3: do like GNU Gettext, except do
not require the primary language in $LANGUAGE to be consistent with LANG
/ LC_ALL.
Thus, we sanitize the environment even harder. What an absolute
disaster. Even if this was fixed tomorrow we would need to maintain this
hack until 2030.
Bug: https://bugs.gentoo.org/936670
Rust-analyzer relies on sysroot to discover its proc-macro server [1] which is
typically installed at <sysroot>/libexec/rust-analyzer-proc-macro-srv. When
used with rust-project.json, rust-analyzer expects the json file to specify
sysroot and fails to launch the proc-macro server otherwise.
So add sysroot to the meson-generated rust-project.json and point it to the
sysroot of the detected rustc compiler.
[1] https://github.com/rust-lang/rust-analyzer/blob/2024-09-16/crates/project-model/src/sysroot.rs#L175
Signed-off-by: Junjie Mao <junjie.mao@hotmail.com>
When `meson dist` fails with the error:
```
Dist currently only works with Git or Mercurial repos
```
It is sometimes inaccurate, since a git repo may exist but be
nonfunctional. Offer some better guidance in that case.
Fixes: #10866
We always pass the string value of the mode to determine_args, which
causes the check on the mode argument inside determine_args to always
evaluate to false.
Fix this by passing the mode itself, not its value.
A common, and challenging, issue in CI runners is debugging issues when
you know the information you want to check, but it's in the log file
which you don't have because remote CI machines.
There are various edge cases where this is especially hard to solve,
such as inside of `pip install` where the build directory with the log
file is automatically cleaned up. But it's never really *easy* when you
don't expect it, and the best case scenario is your iteration time gets
cut in half as you hurriedly go add some `cat`s to your CI scripts.
Meson can, at least sometimes, detect platforms where text can be
emitted inside of "folds", which are auto-collapsed and don't obscure
the general output, but when clicked will expand the logfile contents.
Hook this up.
We start off with a Github Actions implementation. We had some internal
code used by our own project tests runner, which can be utilized.
Also permit forcing it via an environment variable, in case
autodetection fails and you just want to force *something*, especially
when meson is called a couple layers deep inside some other tool.
If a user imports a module and invokes a method on it,
a raw Python exception is raised to the user. This commit
adds a check to ensure that in this case an appropriate
exception is raised instead.
A test has been added to ensure that this exception is
in fact raised on offending code.
Fixes: #11393, #5134
Dylan Baker
Jussi Pakkanen
Andrea Pappacoda
Nirbheek Chauhan
Stephan Lachnit
Raul Tambre
mid-kid
Eli Schwartz
Elliot
Alan Coopersmith
Simon McVittie
Florent Valette
Jonathon Anderson
Tristan Ross
Andrei Alexeyev
Pierre Lamot
paugier
Andrei Horodniceanu
Andrew McNulty
Martin Garton
Will Ayd
unknown
Benoit Pierre
Kacper Słomiński
spaette
Junjie Mao