Since sanity check now includes CFLAGS, the test fails earlier.
But if the compiler is ICC, it will only fail during the build proper as
before, since that's where where the flag making `-std=unknown` an error
not warning is used.
Previously cross, but not native, external args were used. Then in
d451a4bd97 the cross special cases were
removed, so external args are never used.
This commit switches that so they are always used. Sanity checking works
just the same as compiler checks like has header / has library.
I recall that @jpakkane never wanted this, but @nirbheek did, but then
@nirbheek changed his mind.
I am fine either way except for the cross inconsistency that exists
today: There is no `c_preproc_args` or similar one can put in the cross
file, so no way to replicate the effect of CPPFLAGS during cross
compilation.
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.
This can be useful to test a local ninja version (for example while developing
changes to ninja or samurai) without modifying the PATH.
The ninja binary that is detected is then hardcoded in the build.ninja
rules for scan-build and clean, so that it is always used until reconfiguration.
commit b02b2d6d0d462310b313588ca7705d391e830eeb
Author: Michael Hirsch, Ph.D <scivision@users.noreply.github.com>
Date: Sun Mar 10 03:51:09 2019 -0400
cleanup
commit 3311ff5fb12577c78671bf2ff2787d28b86ba5fa
Author: Michael Hirsch, Ph.D <scivision@users.noreply.github.com>
Date: Sun Mar 10 03:50:30 2019 -0400
more robust
commit 8030dcb76698b148ee47ecded1f33b6d3821cca2
Author: Michael Hirsch, Ph.D <scivision@users.noreply.github.com>
Date: Sun Mar 10 03:30:05 2019 -0400
inwork compiles OK but needs smod filenames
This function is used just once. It also seems all policy and no
mechanism (it raises, it calls the same function to do all the work
twice in a simple way). This makes it seem to be as a good candidate for
inlining.
`environment` and `coredata` are woefully intertwined and while this
change doesn't fix that, but at least it makes it easier to follow.
Whenever a non-executable Python script is found by find_program, currently
Haiku and Windows replace a python3 from the shebang line with the one that
was used by Meson. Extend this behavior to POSIX systems so that it is
easy to test a program with multiple Python versions.
Currently this is particularly important for generators, because
they don't allow files in the arguments and thus you cannot do
something like
g = generator(pymod.find_installation(), ...,
arguments: [files('myscript.py'), ...])
With this patch, instead, you can just do
g = generator(find_program('myscript.py'), ...)
This patch creates an enum for selecting libtype as static, shared,
prefer-static, or prefer-shared. This also renames 'static-shared'
with 'prefer_static' and 'shared-static' with 'prefer_shared'. This is
just a refactor with no behavioral changes or user facing changes.
Currently we specialcase OpenMP like we do threads, with a special
`need_openmp` method. This seems like a great idea, but doesn't work
out in practice, as well as it complicates the opemp
implementation. If GCC is built without opemp support for example, we
still add -fopenmp to the the command line, which results in
compilation errors.
This patch discards that and treats it like a normal dependency,
removes the need_openmp() method, and sets the compile_args attributes
from the compiler.
Fixes#5115
Instead of hard-coding the fact that load_configs() searches for files under
meson/native, pass in the subdirectory allowing the cross-file code to use the
same logic.
Meson is not warning if you join paths with / but you are requesting a
version older than 0.49.0; fix this before adding more features to the
division operator.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
For dynamic linking, some mingw releases don't link
correctly with pythonXX.lib in all cases.
This patch forces mingw to link against
pyhthonXX.dll instead of the .lib file, which has
a better compatiblity.
Note that msys 1.0 old platform is detected
as windows instead of 'mingw'
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
John Ericson
John Ericson
Dylan Baker
Jussi Pakkanen
Paolo Bonzini
François Revol
Igor Gnatenko
Michael Hirsch, Ph.D
Jon Turney
Ross Burton
Nacho García
Luca Weiss