This adds support for parsing the new `autolib` member
(https://github.com/rust-lang/cargo/pull/14591).
This is a quick and easy fix, suitable for backport. A larger more
involved fix will be to stop splatting out the cargo dictionaries, and
instead pass the fields we know about 1 by 1, and warning the user if we
come across unknown fields.
Fixes: #13826
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
In the case the main project has a .wrap file for a cargo subproject,
that subproject's Cargo.lock must be loaded before we can recursively
fetch all its dependencies.
The library name defaults to its package name, but it can be different.
For example:
- package name: cairo-sys-rs
- library name: cairo-sys
- dependency name: ffi
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.
This is functionally equivalent to the logic used to locate the cross
exe_wrapper, but puts it below the "Compilers" heading rather than
"Other binaries".
Signed-off-by: Simon McVittie <smcv@debian.org>
Recent versions of the architecture-properties package provide a
cross-exe-wrapper package containing
${DEB_HOST_GNU_TYPE}-cross-exe-wrapper, which is currently a wrapper
around qemu-user but could use different emulators on each architecture
if it becomes necessary in the future.
Signed-off-by: Simon McVittie <smcv@debian.org>
In Debian testing/unstable, there are wrappers available for various
GObject-Introspection tools during cross-builds, using qemu internally.
Signed-off-by: Simon McVittie <smcv@debian.org>
Cross-tools on Debian generally follow the naming convention set by
Autotools AC_CHECK_TOOL, where the name is prefixed with the GNU
architecture tuple for the host architecture. env2mfile was already
using this for pkg-config, but there are many other tools that can
be detected in the same way.
Signed-off-by: Simon McVittie <smcv@debian.org>
Remove trailing periods for consistency with other option descriptions, and use
a consistent description for `winlibs` options everywhere (the one in the
documentation).
`outfilelist` is the output list of the target, while `outfiles` is the output
list of the individual commands
Bug: mesonbuild/meson/pull/13304#issuecomment-2226398671
This setting is for things like `ccache`, but if Meson treats zig that
way, then it will expand the second argument to become:
```
/usr/bin/zig /usr/lib64/ccache/cc
```
in CMake and `/usr/lib64/ccache/cc` is _not_ an argument to `zig`.
If you run
```
$ CC='zig cc' CXX='zig c++' ./meson.py setup 'test cases/cmake/1 basic' build
```
then CMake will fail to compile a "simple test program" and setup
fails.
The first versions of Emscripten that correspond with the Clang version
Meson uses to determine flag support don't actually support the expected
flags. So I went through and picked the first version that actually
worked with the expected flags.
Fixes#13628
macOS mistakenly ships /usr/bin/ncurses5.4-config and a man page for
it, but none of the headers or libraries are available in the location
advertised by it. Ignore /usr/bin because it can only contain this
broken configtool script. Homebrew is /usr/local or /opt/homebrew.
Xcode's command-line tools SDK does include curses, but the configtool
in there is wrong too, and anyway we can't just randomly pick it up
since the user must explicitly select that as a target by using
a native file. The MacOSX SDK itself does not include curses.
We also can't ignore ncurses5.4-config entirely because it might be
available in a different prefix.
`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>
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>
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.
Dylan Baker
Sébastien Villemot
Thibault Saunier
Xavier Claessens
Andoni Morales Alastruey
Simon McVittie
David Robillard
Samuel Thibault
Jussi Pakkanen
Daniele Nicolodi
Pierre Lamot
Kevin Meagher
Loïc Estève
scivision
Elliott Sales de Andrade
Nirbheek Chauhan
mid-kid