It looks like BOOST_ROOT is now set in the azure v2017 image (relevant
change seems to be [1], pre-installing boost)
Remove BOOST_ROOT from the environment to prevent attempting to use a
boost which is incompatible with the compiler.
(an MSVC boost should be compatible with clang-cl, but has problems, see
c7a3e810)
[1] https://github.com/Microsoft/azure-pipelines-image-generation/pull/732
TAP needs to process the test stdout even if --verbose is passed.
Capture it to a separate temporary file, and print it at the end
of the test if --verbose was passed.
In the future, we could parse it on the fly and print the result of
each TAP test point in verbose mode.
Currently InternalDependency.get_partial_dependency shadows the the
input variables names, and then passes those new copies to the final
object returned. It also passes them to the arguments of of
get_partial_dependency for each subdependency, which is wrong. The
code is supposed to proxy the original argumetn values to that instead
of the shadowing values.
To avoid that this patch renames the new values.
Currently if a dependency is added to declare_dependency, and the top
dependency doesn't have an attribute that the subdependency does, it
wont be propagated by subdependency.
It was a mistake in retrospect to not make this deprecated in the
first place, so let's do that. When cross files were new we needed
this as a way to specify a llvm-config binary, since it could be
passed via PATH overrides.
In Fedora 30 the llvm-config binary has the number of bits in the isa
added as a suffic to the name llvm-config-64 or llvm-config-32, and no
naked llvm-config binary is provided. This commit moves the list of
llvm-config binaries to the constructor so that we can modify the list
on a per-instance basis, and adds the new Feodra names.
Fixes#5059
We'll need this in the llvm-config logic to determine the right
llvm-config to call on Fedora 30+, but this feels like the sort of
information that might be useful elsewhere. This does not expose this
information as part of the public API, it's only accessible at the
python layer.
@permittedKwargs() is basically copying the logic of CustomTarget,
but it is not actually up to date, leading to warnings on perfectly
valid values such as 'build_by_default'.
Use CustomTarget.known_kwargs instead, and only append the specific
kwargs of i18n.merge_file().
Fixes https://github.com/mesonbuild/meson/issues/5079
OpenBSD doesn't have any support for the compiler sanitizers yet.
While this may change in the future, better fix test suite run in "failfast"
mode for now. This can be revisited once (if) we get support in the future.
* clang 7.0.1
$ make CFLAGS=-fsanitize=address foo
cc -fsanitize=address -o foo foo.c
cc: error: unsupported option '-fsanitize=address' for target 'amd64-unknown-openbsd6.5'
* gcc 4.2.1
*** Error 1 in /tmp (<sys.mk>:85 'foo')
$ make CC=gcc CFLAGS=-fsanitize=address foo
gcc -fsanitize=address -o foo foo.c
cc1: error: unrecognized command line option "-fsanitize=address"
* gcc 8.2.0
$ make CC=egcc CFLAGS=-fsanitize=address foo
egcc -fsanitize=address -o foo foo.c
ld: error: unable to find library -lasan
collect2: error: ld returned 1 exit status
We need to match the "clang --version" output on OpenBSD:
$ clang --version | head -1
OpenBSD clang version 7.0.1 (tags/RELEASE_701/final) (based on LLVM 7.0.1)
Certain compiler options should affect all platforms for backwards
compatibility. We should probably replace this list with a generic way
to affect all or just one platform.
Builds with Meson 0.50.0 fail in this special case:
[binaries]
c = '.../arm-unknown-linux-uclibcgnueabi/bin/arm-unknown-linux-uclibcgnueabi-gcc'
...
[binaries]
exe_wrapper = 'qemu-arm-static'
...
[properties]
c_link_args = ['-static']
...
The sanity check output is not a static binary, as it used (and expected to be)
with Meson < 0.50.0. The crosstool-ng built uClibc is not present in the
build machine's /lib, so the sanity check fails.
This bug was introduced in d451a4bd97.
This partially reverts that for 0.50.*. master will instead always use
this flags in cross and native alike for consistency.
This defines 'is_cross_build()` in terms of whether we have a cross
file, not whether `build_machine == host_machine`.
This should only be used in 0.50.*. The better fix for master is #4010,
which keeps the existing `is_cross_build()`, but allows separate
compilers targetting the build and host machine in all cases. These
points in the direction of Meson being agnostic to whether the build is
a cross build, and `is_cross_build()` just being a convenience for the
user.
Fixes#5102
Martin Hostettler
Jon Turney
GoaLitiuM
Nirbheek Chauhan
Anton Kochkov
Daniel Mensinger
Elliott Sales de Andrade
Jussi Pakkanen
Paolo Bonzini
Janne Grunau
Dylan Baker
François Revol
Ninja-Koala
Georges Basile Stavracas Neto
Antoine Jacoutot
Ignacio Casal Quinteiro
John Ericson
Dima Krasner
John Ericson
Amit D