The D stdlib function std.process.spawnProcessPosix suffers from a bug
that causes any program that calls it to OOM if the nofile ulimit is
large.
This doesn't affect CI currently but trying to run or build the
containers locally will most likely crash when calling dub as docker
defaults to something like 1073741816 for both the hard limit and soft
limit. Lowering the soft limit is enough to make dub behave.
Signed-off-by: Andrei Horodniceanu <a.horodniceanu@proton.me>
`DEB_HOST_ARCH` encodes both the CPU family and the OS, so using it to
get the CPU type gives the wrong answer for non-Linux ports.
However, `DEB_HOST_GNU_CPU` gives less detailed information about the
CPU: it's `arm` for all 32-bit ARM CPUs, and doesn't distinguish between
the differing baselines of `armel` (ARMv5 softfloat) and `armhf`
(ARMv7 hardfloat).
When cross-compiling for x86_64 Linux, this changes the `cpu()` from
`amd64` to `x86_64`, which is consistent with the answer we get during
native builds on that architecture.
When cross-compiling for `ppc64el`, this changes the `cpu()` from
`ppc64el` to `ppc64`, which is a reasonable change but is still not
consistent with what we see during native builds (which is `ppc64le`):
see #13741 for that.
Resolves: https://github.com/mesonbuild/meson/issues/13742
Signed-off-by: Simon McVittie <smcv@debian.org>
All official Debian release architectures use the Linux kernel, but
unofficial ports like hurd-i386 and kfreebsd-amd64 use the Hurd and
FreeBSD kernel, respectively.
Map Linux to 'linux' and kFreeBSD ports to 'freebsd' as per the
reference tables in Meson's documentation. For now, use the Debian
system name such as 'hurd' for anything else (see #13740 for the
question of whether Hurd should identify its kernel differently).
Signed-off-by: Simon McVittie <smcv@debian.org>
As per <https://mesonbuild.com/Reference-tables.html>, and matching what
happens when running Meson for a native build on Debian GNU/Hurd.
Signed-off-by: Simon McVittie <smcv@debian.org>
This makes the frequent pattern of things like "CPU families are the
same as GNU CPUs, with a few known exceptions" less verbose.
Signed-off-by: Simon McVittie <smcv@debian.org>
This test parses several possible outputs of dpkg-architecture and
asserts that they produce the expected MachineInfo.
To avoid depending on suitable cross-tools being installed, use
unittest.mock to override locate_path with a version that pretends that
all of the tools we're interested in are in /usr/bin.
Similarly, use mock environment variables to exercise what happens
when we have those set.
The test data used here exercises most variations:
* big- and little-endianness
* GNU CPU (x86_64) differing from dpkg CPU (amd64)
* Linux, kFreeBSD and Hurd
* special-cased architectures: x86, arm, mips64el, ppc64el
expected_compilers() intentionally doesn't assume that every compiler
is gcc (even though they all are, right now), because #13721 proposes
adding valac which does not take a gcc suffix.
Signed-off-by: Simon McVittie <smcv@debian.org>
Separating the part that runs dpkg-architecture from the part that
interprets its results will make it easier to unit-test the latter.
Signed-off-by: Simon McVittie <smcv@debian.org>
This will make it easier to unit-test functions that work with a
MachineInfo, by constructing the expected object in a single call.
Signed-off-by: Simon McVittie <smcv@debian.org>
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>
This is never set outside the `Compiler.__init__`, only added to. As
such there's no reason to have this `hasattr` check. It's wasting time
*and* confusing our static checkers.
This is used in exactly two cases, and it's just not worth it. Those two
cases can override the default set of extensions, and in the process
allow a nice bit of code cleanup, especially toward type checking.
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>
Andrei Horodniceanu
Simon McVittie
Dylan Baker
Eli Schwartz
mid-kid
Jussi Pakkanen
Andrea Pappacoda
Nirbheek Chauhan
Stephan Lachnit
Raul Tambre
Elliot
Alan Coopersmith
Florent Valette
Jonathon Anderson
Tristan Ross
Andrei Alexeyev
Pierre Lamot
paugier