This avoids the duplication where the option is stored in a dict at its
name, and also contains its own name. In general, the maxim in
programming is things shouldn't know their own name, so removed the name
field just leaving the option's position in the dictionary as its name.
Also, we should at some point decide whether we're going to use American
spelling (serialize/serialization) or British (serialise/serialisation)
because we have both, and both is always worse than one or the other.
This function is currently setup with keyword arguments defaulting to
None. However, it is never called without passing all of it's arguments
explicitly, and only one of it's arguments would actually be valid as
None. So just drop that, and make them all positional. And annotate
them.
I wanted to look at the imports for annotations but was having hard time
reading them because they're just all over the place. This is purely a
human readability issue.
Intel helpfully provides a cl.exe that is indistinguishable from
Microsoft's cl.exe in output, but has the same behavior as icl.exe.
Since icl and ifort will only be present in your path if you've started
an Intel command prompt search for that first.
The Intel compiler is strange. On Linux and macOS it's called ICC, and
it tries to mostly behave like gcc/clang. On Windows it's called ICL,
and tries to behave like MSVC. This makes the code that's used to
implement ICC support useless for supporting ICL, because their command
line interfaces are completely different.
This restrictuion exists for MSVC and clang-cl, but not for ICL which
actually does support C++11 as a distinct standard. This commmit pulls
that behavior out into a mixin class for ClangClCPPCompiler and
VisualStudioCPPCompiler, as well as moving the MSVC specific
functionality into the VisualStudioCPPCompiler class.
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.