It appears that LIB/LINK default to the host architecture if they can't
guess it from the first object. With the MSVC toolchain, resource files
are (usually) compiled to an arch-neutral .res format. Always
explicitly provide a '/MACHINE:' argument to avoid it guessing
incorrectly when cross-compiling.
The documentation states: "In other cases you can get multi-line
statements by ending the line with a \." but that seems to never have
worked.
Closes: #4720
Building a cross compiler (`build == host != target`) is not cross
compiling. As such, it doesn't make sense to handle it under
`is_cross_build`.
(N.B. Building a standard library for a cross compiler would require
cross compiling, but Meson has support to do such a thing as part of a
compiler build currently.)
Previously, the configuration worked fine, but the compiler raised an
error. Now, we explicitly check for the existence of files and print a
useful error message if they do not exist.
This seems to be related to deleting the current working directory.
Simply deleting all of the trees inside the build directory instead
seems to fix it. This only appears with some combination of generated
targets, running the test case against say "1 trivial" doesn't show the
bug.
See this mesa bug: https://bugs.freedesktop.org/show_bug.cgi?id=109071
It is possible that the subproject has been downloaded already, in that
case there is no reason to not use it. If the subproject has not been
downlaoded already it will fail do_subproject().
The code our projects care about verifying coverage for mostly lives in
the source_root with the exception of the generated source files in
build_root. This change cleans up the output so we don't have prefixed
paths on our source files anymore.
This would normally be exposed by the ExternalProgramHolder, but wasn't
due to the implementation of the PythonInstallation module. Because of
that I've duplicated the method so that we can add the FeatureNew
decorator.
Fixes#4070