| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
|/ |
|
| |
|
|
|
|
| |
- Typos were found by codespell v1.16.0
|
| |
|
|
|
|
|
|
| |
Now that the linkers are split out of the compilers this enum is
only used to know what platform we're compiling for. Which is
what the MachineInfo class is for
|
|\
| |
| | |
Add is_system to dependency
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
class
Instead of the DynamicLinker returning a hardcoded value like
`-Wl,-foo`, it now is passed a value that could be '-Wl,', or could be
something '-Xlinker='
This makes a few things cleaner, and will make it possible to fix using
clang (not clang-cl) on windows, where it invokes either link.exe or
lld-link.exe instead of a gnu-ld compatible linker.
|
|
|
|
|
| |
Most of the cuda code is from Olexa Bilaniuk.
Most of the PGI code is from Michael Hirsc
|
| |
|
|
|
|
|
| |
Do not set -Wl,-headerpad_max_install_names when compiling on OSX for
another platform. It causes linker issues.
|
|
|
|
| |
This simplifies and cleans things up.
|
| |
|
|
|
|
|
|
|
|
|
| |
There are two problems, one is that it assumes -flto is the argument
to do LTO/WPO, which isn't true of ICC and MSVC (and presumably)
others. It's also incorrect because it assumes that the compiler and
linker will always be the same, which isn't necessarily true. You
could combine GCC with Apple's linker, or clang with link.exe, which
use different arguments.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
There is a pretty big error in here, trying to return a tuple
comperhension: (a for a in []) is not a tuple, it's a generator. This
has profound type annotations: generators don't support most tuple or
list methods, and they can only be iterated once. Beyond that tuples are
meant for heterogenous types, ie, position matters for types. I've
converted the output to a list in all cases.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
I debated a bit whether both classes really belong in the same module,
and decided that they do because the share a number of helpers.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- AttributeError: 'ValaCompiler' object has no attribute 'get_program_dirs'
Fixed by adding a `get_program_dirs()` function to the base Compiler
class, to match `get_library_dirs()`
- KeyError: 'vala_COMPILER'
Fixed by creating the Vala compile rules for all machines, not just
the build machine.
|
| |
|
| |
|
|
|
|
| |
Fixes #5351
|
|
|
|
| |
Revert the change done to Armclang compiler class in PR-4010
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
ICL (Intel for Windows) support
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
ICL needs ot use some of this code, but not from it's own version
information.
|
| |
| |
| |
| |
| | |
Becuase treating args as either keyword or positional makes inheritance
really awful to work with.
|
|/
|
|
|
|
| |
head to converge it to the solaris 11.4 platform based on the sparcv9 and i386 processor architecture.
The purpose is to complete the porting related to the fork "sneyx1234/ast" of "att/ast" the "AT&T kornshell".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
Cache compilers.compile() in coredata
|