Some slight refactoring for the dependency classes and
I switched the elbrus compiler to the GnuLikeCompiler.
This is also the correct use according to the documentation
of GnuLikeCompiler.
This puts appropriate default options across buildtype for Intel and
Intel-Cl compilers, for C, C++ and Fortran. Prior to this PR, the
behavior of Intel compilers vs. GNUlike was not the same, in
particular, debug traceback available by default for GNUlike compilers
was not present with Intel compilers.
Fixes PR #6166 and more specifically commit 4e460f04f3 that tried to
make sure the type of a key variable is a string but checked the type of
the value instead. Extends test common/228's limited coverage,
its only test case had (surprise) a string value. Also avoid reserved
python keyword 'dict' and potentially confusing string 'key'.
Implements #5231 for real.
This is returning the inverse of the correct value, which happens to
work out because in general the compilers that a link.exe-like linker is
paired with accepts the same arguments.
This dumps xild on mac and linux. After a lot of reading and banging my
head I've discovered we (meson) don't care about xild, xild is only
useful if your invoke ld directly (not through icc/icpc) and you want to
do ipo/lto/wpo. Instead just make icc report what it's actually doing,
invoking ld or ld64 (for linux and mac respectively) directly. This
allows us to get -fuse-ld working on linux.
Since I spent three days banging my head against this it seems
reasonable that other people might also run into this problem. It can
happen if you're trying to use microsoft's link.exe, but also have the
dmd bin directory at the tail of your %PATH%, among other reasons.
Since we pass the whole compiler class (as a type()) we don't need to
also pass it's LINKER_PREFIX attribute, we can just get it from the
type we're passing.
Rather than trying to figure out if we're using MSVC based on
environment variables, then trying to get the C compiler and test some
attributes, get the C compiler and see if it's MSVC. This is much more
reliable and we were already doing it anyway.
Normally MPI programs would be run with MPI exec, but Travis-CI
has errors wanting --allow-run-as-root. To simplify, we don't use
mpiexec in this test, since it's a library check, not an MPI stack check.