| Age | Commit message (Collapse) | Author |
|---|
|
This simplifies a bunch of cases, and likely fixes some annoying bugs
in cross compile situations where should have been passing this and
weren't.
|
|
It's allowed in the `DependencyKeywordArguments` TypeDict already, so we
now have two sources of truth. Additionally, it's often populated by
reading from that dict, so we're just doing useless work.
|
|
|
|
|
|
For the same reason that the StaticLinker needs this, we need it in the
DynamicLinker as well.
|
|
This is calculated by `Environment().is_cross_build(for_machine)`. Since
we have that in the Compiler class, just calculate it in the Compiler
initializer
|
|
We end up needing it everywhere, so just store it. This patch is huge
already, so it's just the conversion to passing Environment, more
cleanups to come.
|
|
We don't always check if a library is actually linkable because of concerns
that a library may not be standalone, so linking against it may still have
unresolved references. We can workaround that by building a shared library
as a test rather than an executable, and in fact we already do that in a
bunch of cases since bb5f2ca3da821d7a8e865cd55a8d5d638e0aab22.
This comes up in particular with Fedora and dependency('atomic') because
on x86_64, they provide a libatomic.so linker script (so our file existence
check passes), but trying to use it later on will fail if the backing package
isn't installed.
_get_file_from_list has not been deleted because the Ninja backend's
guess_library_absolute_path uses it. We might be able to change it to
also use a link test but I've left that alone.
Test notes:
* The _test_all_naming unittest has been tweaked because we were using a
blank file rather than an actual shared library, which (as expected),
now fails.
* I've also added a test for dependency('atomic') providing a result that
can actually be linked against. I've not made it check generally whether
dependency('atomic') finds something when we expect to (at least for now)
as it'll involve some CI whack-a-mole.
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2352531
Bug: https://github.com/mesonbuild/meson/issues/14946
Closes: https://github.com/mesonbuild/meson/issues/10936
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
As with many compilers and other tools relevant to cross-compiling,
an executable prefixed with the host architecture's GNU architecture
tuple might or might not exist, but if it does exist, we can be quite
confident that it's the appropriate executable to use for that host
architecture.
Vala's vapigen tool reads GIR XML files that can vary between
architectures (for example GLib-2.0.gir and GstAudio-1.0.gir contain
constants that take architecture-specific values), so on Debian it
needs to search an architecture-specific location. Accordingly, the
valac (>= 0.56.18-3) package provides a `${DEB_HOST_GNU_TYPE}-vapigen`
script which wraps the vapigen binary and sets appropriate search paths.
Bug-Debian: https://bugs.debian.org/1116552
Signed-off-by: Simon McVittie <smcv@debian.org>
|
|
It does not seem to be needed anymore, and the incomplete mock does
not have for example the "yielding" attribute that is used by
OptionStore.get_value_object_and_value_for.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
In a3679a64e (programs: favor version numbers with dots, 2025-01-03) we
have changed the regex used to extract version numbers to favor dotted
versions. It was reported though that the regex doesn't match major
version numbers that start with multiple digits correctly. Fix this.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
|
|
When using `find_program('perl')` we misdetect its version number:
Program perl found: YES 40 40 (/usr/bin/perl)
This is caused by Perl outputting the version information in a somewhat
weird format:
$ perl --version
This is perl 5, version 40, subversion 0 (v5.40.0) built for x86_64-linux-thread-multi
...
The problem here is that our version number detection picks the first
match of at one digit followed by at least one more digit and/or dot.
Consequently, as "40" matches that regular expression, we'd return its
value as the version number.
Naturally, the version number detection we perform is best-effort, only,
as there is no standardized format used by all programs. That being
said, we can do better here by first trying to match a dotted version
number so that we'd match the "5.40.0" string, not the "40". And given
that most projects use dotted version numbers this should be a strict
improvement in cases where we have multiple digits in-text. The old
behaviour continues to be used as a fallback though in case we weren't
able to match anything to not regress functionality.
The new regex also fixes another case: when the version information ends
with a trailing dot, like "foo version 1.2.3.", then we'd also have
matched that trailing dot. This can be for example the case when version
numbers end with ".rc1" or something similar. While we'd ideally include
such suffixes into the detected version, that issue is left for another
day.
Add a couple of tests.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
|
|
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>
|
|
uname -s does return gnu there.
Resolves: https://github.com/mesonbuild/meson/issues/13740
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
|
|
`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 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>
|
|
|
|
This function is no longer used since shutil.which() is used instead.
|
|
|
|
|
|
|
|
The documentation for subprocess.run at https://docs.python.org/3/library/subprocess.html#popen-constructor has a warning,
pointing to using shutil.which() instead of subprocess.run for detecting if exe files exists on the path.
shutil.which() is used in many places already.
|
|
|
|
|
|
@PLAINNAME@ and @BASENAME@ cannot be used in custom_target()
with multiple inputs. For those, similar macros are needed
with an index.
Fixes #13164
|
|
When only a single input file shows up in an arglist, it makes no sense
to inject `-W,--start-group -lone -Wl,--end-group`, since there is
nothing being grouped together. It's just longer command lines for
nothing.
|
|
Python provides some nifty tools for mocking, without relying on
altering running code. We should use these to simplify the actual run
paths and move the complicated logic into tests.
|
|
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
|
|
The unit test infrastructure hardcodes the architecture as x86_64. On
macos, the test_pkgconfig_parse_libs() test creates a few libraries
for testing using clang. This leads to the test failing on arm based
macs, as darwin_get_object_archs() will skip over these libraries,
which then leads to the test failing because of using -l instead of
referencing the libraries by their full path.
I am not at all sure this is the best approach.
I am also somewhat confused why nobody else has encountered this? CI
apparently just runs on x86_64 macs?
CC: @tristan957
|
|
The former has rust dependencies, which lead to max capping on Cygwin
since there is no rust compiler there. But it turns out there are other
disadvantages of jsonschema:
- it involves installing 5 wheels, instead of just 1
- it is much slower
To give some perspective to the latter issue, this is what it looks like
when I test with jsonschema:
```
===== 1 passed, 509 deselected in 3.07s =====
Total time: 3.341 seconds
```
And here's what it looks like when I test with fastjsonschema:
```
===== 1 passed, 509 deselected, 1 warning in 0.28s =====
Total time: 0.550 seconds
```
I cannot think of a good reason to use the former. Although in order to
work on old CI images, we'll support it as a fallback mechanism
|
|
|
|
It should *be* a version comparison. We are guaranteed to get a
two-element version number, which also parses as a float but a float
doesn't correctly handle version sorting when the second component
differs in number of digits.
The standard way to handle this is by comparing tuples such that each
component is an integer. Do so here.
Fixes #12195
Co-authored-by: George Koehler <xkernigh@netscape.net>
(for unittests)
|
|
Reproduces: https://github.com/mesonbuild/meson/issues/12017
Signed-off-by: Simon McVittie <smcv@debian.org>
|
|
In some cases the desired result can be different if there are no
compilers at all. The expectations here are based on there being at
least one compiler, so reflect that by providing one; a later test
enhancement can cover the case where there are no compilers provided.
As a result of the mock any_compiler_has_define(), all that matters
will be the distinction between an empty or non-empty dict: the compiler
object itself is unused.
Signed-off-by: Simon McVittie <smcv@debian.org>
|
|
This makes the code cleaner and will allow to have other implementations
in the future.
|
|
By specifiying explicit encodings, we can silence warnings like:
/__w/meson/meson/test cases/common/100 postconf with args/postconf.py:15: EncodingWarning: 'encoding' argument not specified
with open(input_file) as f:
in CI.
|
|
This saves on a 1500-line import at startup and may be skipped entirely
if no compiled languages are used. In exchange, we move the
implementation to a new file that is imported instead.
Followup to commit ab20eb5bbc21ae855bcd211131132d2778602bcf.
|
|
This lessens the amount of code imported at Meson startup by mapping
each dependency to a dictionary entry and using a programmable import to
dynamically return it.
Minus 16 files and 6399 lines of code imported at startup.
|
|
This is a pretty common pattern in python (the standard library uses it
a ton): A class is created, with a single private instance in the
module, and then it's methods are exposed as public API. This removes
the need for the global statement, and is generally a little easier to
reason about thanks to encapsulation.
|
|
MIPS64 can run MIPS32 code natively, so there is a chance that a mixture
of MIPS64 kernel and MIPS32 userland exists. Before this Meson just
treats such mixture as mips64, because uname -m returns mips64.
So in this case we have to check compiler builtin defines for actual
architecture and CPU in use.
- Also fixes mips64 related detection tests in internaltests:
Normalize mips64 as mips first, then if __mips64 is defined, return
mips64 for mips64* machines.
This is a bit confiusing because normally one would detect if a flag
of 32-bit target is defined while running on a 64-bit machine. For
mips64 it is almost just the other way around - we need to detect if
__mips64 is set to make sure it is a mips64 environment.
Co-Authored-By: Jue Wang <maliya355@outlook.com>
|
|
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
|
|
|
|
Now that we don't insert /utf-8 into the always args for MSVC < 19.00
we need to use a version > 19.00 for testing. This also means that
/Zc:__cplusplus will be added to the always args.
|
