This brings the formatting more in line with other modules, in
particular the headers do not include the full function signature for
readability, keyword arguments are listed one-by-one, etc.
Do not run tests that use integers in versions with compiler that do
not support them.
Old versions of GDC supported plain integers in version and debug
strings but they are deprecated and GDC 13 hard errors on them.
These result in very large binaries when linked, and are not generally
useful. A user can turn them back on by passing `-C overflow-checks=yes`
manually via `-Drust_args` or the `RUSTFLAGS` environment variable
fixes: #11785
In order to pass a File object down into the compiler impl and compile
it, we cannot pass a string with the filename, and we cannot either pass
the File object as-is, since it relies on being given Environment
attributes to calculate the relative location. So we build a fresh File
object as an absolute path.
But the code to do this was totally broken. Instead of using the File
method to get an absolute path, we used one that expected to create
builddir-relative paths... and then gave it the absolute source dir as
the "relative path portion" prefix. This worked by accident as long as
it wasn't a built File, but if it was a built file then we intentionally
didn't include that prefix -- which was wrong anyway, since we need the
build directory!
Use the correct method to get an absolute path in all cases, and emit a
warning if it was a built file. This never worked. Sometimes it crashed,
sometimes it silently returned false.
Fixes#11983
GCC 12.3 and Clang 16 support -std flags for c++23/c++2b. The unreleased
GCC 14 and Clang 17 will support -std flags for c++26/c++2c.
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
The c++23 mappings apply to current production compilers (GCC, Clang).
None of the production c++ compilers support c++26 flags yet, but this
mapping will be ready once they do.
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
On windows, meson would mix posix and windows dir separators in the
computed PACKAGE_RELATIVE_PATH.
Here we force posix directory separator even on Windows. This matches
the CMake behavior and fixes interpretation of the resulting path.
Fixes#6955Fixes#9702
Some macos libraries use arm64e instead of arm64 as architecture. Due to the
string replace approach taken so far, we'd end up with aarch64e as
architecture, which the rest of meson doesn't know.
Move architecture mapping to map whole architecture names and add arm64e ->
aarch64 mapping.
This change doesn't touch the case for armv7[s], where we add arm, rather than
replace armv7[s], but it's certainly not in line with the other mappings.
Fixes: #9493
Co-authored-by: Tristan Partin <tristan@partin.io>
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.
Replace unencodable XML chars with their printable representation, so
that, xmllint can parse test outputs without error.
Closes#9894
Co-authored-by: Tristan Partin <tristan@partin.io>
Cython historically, when asked to print the version and exit
successfully, would do so on stderr, which is weird and inconsistent.
Recently, it fixed this UX bug by printing on stdout instead:
https://github.com/cython/cython/issues/5504
This then broke meson detection because we assumed it was on stderr due
to historically being there:
https://github.com/scipy/scipy/issues/18865
Cython is right, and shouldn't have to revert this reasonable change for
backwards compatibility. Instead, check both.
There are some new(er) methods that have not version reference, so add
the missing ones in order to be properly notified when targetting older
meson versions.
Co-authored-by: Tristan Partin <tristan@partin.io>
Instead of hardcoding any values, hardcode what we think the most likely
implementation is, and check that first. It was pointed out that while
for example, Apple only provides libc++ and supports that for xcode, a
user could install a custom environment (such as homebrew) which uses
it's own copy of libstdc++, and we need to account for that. This means
that a library search will be done, but only once and the result will be
cached, on all systems.
It is not the primary purpose of mtest, and it ends up mingled with a
list of actual tests, which isn't nice if you're trying to capture and
parse this.
In commit 628effb369 we started verifying
the build.ninja file was up to date before even `--list`ing tests,
because we could end up with incorrect information. This meant that
ninja always runs at startup, and typically returns "no work to do",
which ended up listed as "one of" the tests.
Instead of unconditionally running ninja attached to the console, first
check it in dry-run mode with stdout intercepted, to see if ninja
considers itself up to date. If it is, continue. Only if an actual
refresh is needed, do we run it while attached to the console.
In the garden path, this avoids useless information. In cases where we'd
already print a full meson reconfigure log, we continue to do so.
By default, clang-cl based environments use rc.exe as resource
compiler. However, when cross compiling with clang-cl, one might
want to use llvm-rc instead.
Try to detect llvm-rc based on the output from "$CMD /?".
This requires a very recent llvm-rc; previosly, the output of
"/?" with llvm-rc was very generic and didn't explicitly indicate
that it actually was llvm-rc. This was changed in
bab6902eba
which will be included in the upcoming LLVM 17.0.0 release.
Contrary to the other regexes, don't include the preceding parts
of the line in the log printout, as it includes an unhelpful
"OVERVIEW:" prefix.
This fixes regression caused by
3162b901ca
that changes the order in which libraries are put on the link command.
In addition, that commit was wrong because libraries from dependencies
were processed before process_compiler() is called, which that commit
wanted to avoid.
When downloading wrap content, we need to know at some point if the
server is going to respond with "hello, yes, I'm here and I have data
for you". The alternative is to sometimes infinitely hang.
In commit 8f7781f1d6 we added such a
timeout, but using an extremely generously high number -- ten minutes.
We don't need to wait this long just to find out if the other end
exists, so decrease that time to 30 seconds, whch is still ludicrously
generous but not quite as much so.
This reverts commit 904b47085f.
This is not a real bottleneck, and we want to create it thrice -- once
before the backend is generated. The final install data needs to be
created fresh.
Update unittest to demonstrate the issue.
Fixes https://bugs.gentoo.org/910050
Eli Schwartz
Peter Hutterer
Xavier Claessens
Jussi Pakkanen
Dylan Baker
Steven Noonan
Matthieu Rogez
Andres Freund
Charles Brunet
Tristan Partin
Nazir Bilal Yavuz
MiroPalmu
Marco Trevisan (Treviño)
Martin Storsjö
Rafael Silva