Ifort can generate dependency information (.d files), it just does it
differently than GNU compilers do. This also fixes a bug caused by
adding the dependency generation commands to the GNULike class later in
this series.
The compilers module is rather large and confusing, with spaghetti
dependencies going every which way. I'm planning to start breaking out
the internal representations into a mixins submodule, for things that
shouldn't be required outside of the compilers module itself.
In most cases instead pass `for_machine`, the name of the relevant
machines (what compilers target, what targets run on, etc). This allows
us to use the cross code path in the native case, deduplicating the
code.
As one can see, environment got bigger as more information is kept
structured there, while ninjabackend got a smaller. Overall a few amount
of lines were added, but the hope is what's added is a lot simpler than
what's removed.
Apparently we have no tests for this because this is broken pretty
badly. This extends the basic test to actually check for the correct
free-form argument and thus test this.
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.
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.
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.
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.
This allows each implementation (gnu-like) and msvc to be implemented in
their respective classes rather than through an if tree in the CCompiler
class. This is cleaner abstraction and allows us to clean up the Fortran
compiler, which was calling CCompiler bound methods without an instance.
Because we need to inherit them in some cases, and python's
keyword-or-positional arguments make this really painful, especially
with inheritance. They do this in two ways:
1) If you want to intercept the arguments you need to check for both a
keyword and a positional argument, because you could get either. Then
you need to make sure that you only pass one of those down to the
next layer.
2) After you do that, if the layer below you decides to do the same
thing, but uses the other form (you used keyword by the lower level
uses positional or vice versa), then you'll get a TypeError since two
layers down got the argument as both a positional and a keyword.
All of this is bad. Fortunately python 3.x provides a mechanism to solve
this, keyword only arguments. These arguments cannot be based
positionally, the interpreter will give us an error in that case.
I have made a best effort to do this correctly, and I've verified it
with GCC, Clang, ICC, and MSVC, but there are other compilers like Arm
and Elbrus that I don't have access to.
* Enums are strongly typed and make the whole
`gcc_type`/`clang_type`/`icc_type` distinction
redundant.
* Enums also allow extending via member functions,
which makes the code more generalisable.
Dylan Baker