There are two cases that won't work (these are taken from fortran/9
cpp), using gfortran with a non-gcc compiler on windows, or using
gfortran with apple clang. The latter is due to default search paths,
which we can fix, but is out of scope for this MR.
Instead of the default ones, this is especially important when cross
compiling or when using compilers that aren't compatible with the
default ones.
squash! dependencies/hdf5: Use the actual system compilers
mypy noticed that we were passing [] (instead of a dict or None) to the
ClangCompiler class in objc, which made me noticed that for C and C++ we
set the defines, but not for ObjC and ObjC++
We do this by making the mixins inherit the Compiler class only when
mypy is examining the code (using some clever inheritance shenanigans).
This caught a bunch of issues, and also lets us delete a ton of code.
Every class needs to set this, so it should be part of the base. For
classes that require is_cross, the positional argument remains in their
signature. For those that don't, they just allow the base class to set
their value to it's default of False.
Currently we do some crazy hackery where we add extra properties to a
Popen object and return that. That's crazy. Especially since some of our
hackery is to delete attributes off of the Popen we don't want. Instead,
let's just have a discrete type that has exactly the properties we want.
This is still missing completions for promote, but I can't figure out
how to find the wraps in subprojects that are not in the parent project
when those projects haven't been fetched yet.
Those function are common source of issue when used in a subproject because they
point to the parent project root which is rarely what is expected and is a
violation of subproject isolation.
We're using these now, so having some error checking to make sure we
don't have paths were we're trying to instantiate an abstract class
would be good.
This catches some very real errors.
The one in scalapack is pretty silly actually, it's failing to figure
out that the exploded list is at least two arguments. However, the code
is actually clearer by not using a list and exploding it, so I've done
that and pylint is happy too.