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.
- 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.
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.
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.
When the '-Wl,-rpath-link' option refers to several folders, we can
either use one single entry, like this:
-Wl,-rpath-link,/path/to/folder1:/path/to/folder2:/path/to/folder3
...or we can use multiple entries, like this:
-Wl,-rpath-link,/path/to/folder1
-Wl,-rpath-link,/path/to/folder2
-Wl,-rpath-link,/path/to/folder3
Because the '-rpath-link' requires full folder paths, using the one
single entry option can result in a very long argument.
While this shouldn't be a problem, at least *one* toolchain (the latest
version of the Tensilica toolchain for Xtensa processors) segfaults when
using arguments that are too long.
Because other toolchains might be affected and because using multiple
entries instead of a very long one doesn't seem to have any drawback,
this patch changes the arguments building logic to use multiple
'-Wl,-rpath-link' entries.
I recall that @jpakkane never wanted this, but @nirbheek did, but then
@nirbheek changed his mind.
I am fine either way except for the cross inconsistency that exists
today: There is no `c_preproc_args` or similar one can put in the cross
file, so no way to replicate the effect of CPPFLAGS during cross
compilation.
OpenBSD does not link libc into shared libraries by default to avoid binding
libraries to specific libc majors. So prevent passing "-Wl,--no-undefined" or
"-zdefs" when linking (those options have always suffered false positives on
this operating system).
Dylan Baker
Nirbheek Chauhan
Daniel Mensinger
Norbert Nemec
Charlie Barto
James Westman
Cody Schafer
Roman Shpuntov
Kurtis Rader
sompen
John Ericson
John Ericson
Simon Ney
Michael Hirsch, Ph.D
Fernando Ramos
makise-homura
Jon Turney
Jussi Pakkanen
Antoine Jacoutot