There actually is an ICC for windows that can be used to cross compile
from Windows to Linux, but it's not supported in meson currently and I
don't plan to enable it.
This test currently assumes that the fortran compiler is gfotran, and
if we're not using g++ it skips. This patch changes it to skip if the
fotran compiler and the c++ compiler aren't the same family. This still
may skip in some cases it shouldn't (clang and gfort probably work fine
on windows), but it does enable ifort + ICL. Which is hte point.
Currently C++ inherits C, which can lead to diamond problems. By pulling
the code out into a standalone mixin class that the C, C++, ObjC, and
Objc++ compilers can inherit and override as necessary we remove one
source of diamonding. I've chosen to split this out into it's own file
as the CLikeCompiler class is over 1000 lines by itself. This also
breaks the VisualStudio derived classes inheriting from each other, to
avoid the same C -> CPP inheritance problems. This is all one giant
patch because there just isn't a clean way to separate this.
I've done the same for Fortran since it effectively inherits the
CCompiler (I say effectively because was it actually did was gross
beyond explanation), it's probably not correct, but it seems to work for
now. There really is a lot of layering violation going on in the
Compilers, and a really good scrubbing would do this code a lot of good.
Mypy know what to do with these and isn't confused, but some versions of
python 3.5 (at least 3.5.2) can't handle these annotations. By making
them strings the python interpreter wont try to evaluate them.
Fixes#5326
When we create a dependency as part of another dependency (say Threads),
we want to pass down most of the methods (like required). Currently
however, there is the possibility that we can pass down invalid keyword
arguments, such as 'method'. This new method is meant to work around
that my simplifying and centralizing how we pass these dependencies
down.
It turns out there's a bug in creating a sub dependency out of threads
in that we pass all of the kwargs from the parent to the
ThreadDependency instance. This demonstrates the bug.