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).
Before, the logic initialization compiler options from environment
variables vs config files was strewn about. Now, it is consolidated. We
leverage the new `envconfig.py` module to expose the configuration data
to `compilers.py` without creating an import cycle.
This does two things:
* On windows GCC-like compilers, the subsystem is always explicitly
specified (either -mwindows or -mconsole). MSVC is already explicit.
* The gui_app linker flags are now added after those mandated by
external dependencies. This is because some misguided libraries (such
as SDL) think that hijacking `main()` and forcing `-mwindows` in link
flags is clever. We must unconditionally override such misuses to let
gui_app work as intended.
Instead use coredata.compiler_options.<machine>. This brings the cross
and native code paths closer together, since both now use that.
Command line options are interpreted just as before, for backwards
compatibility. This does introduce some funny conditionals. In the
future, I'd like to change the interpretation of command line options so
- The logic is cross-agnostic, i.e. there are no conditions affected by
`is_cross_build()`.
- Compiler args for both the build and host machines can always be
controlled by the command line.
- Compiler args for both machines can always be controlled separately.
Kurtis Rader
sompen
John Ericson
John Ericson
Dylan Baker
Simon Ney
Daniel Mensinger
Michael Hirsch, Ph.D
Fernando Ramos
makise-homura
Jon Turney
Jussi Pakkanen
Nirbheek Chauhan
Antoine Jacoutot
jml1795
Andrei Alexeyev
Beau Johnston