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.
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.
ICC doesn't use the same -fprofile-generate/-fprofile-use that GCC and
Clang use, instead it has -prof-gen and -prof-use. I've gone ahead and
added the threadsafe option to -prof-gen, as meson currently doesn't
have a way to specify that level of granularity and GCC and Clang's
profiles are threadsafe.
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.
Some compilers try very had to pretend they're another compiler (ICC
pretends to be GCC and Linux and MacOS, and MSVC on windows), Clang
behaves much like GCC, but now also has clang-cl, which behaves like MSVC.
This method provides an easy way to determine whether testing for MSVC
like arguments `/w1234` or gcc like arguments `-Wfoo` are likely to
succeed, without having to check for dozens of compilers and the host
operating system, (as you would otherwise have to do with ICC).
Replace several checks against GCC_MINGW or (GCC_MINGW, GCC_CYGWIN) with
is_windows_compiler instead, so that clang and other gcc-like compilers
using MinGW work appropriately with vs_module_defs, c_winlibs, and
cpp_winlibs.
Fixes#4434.
This allows using the imperfect profiles generated by multithreaded
programs. Without the argument, GCC fails to load them.
Clang just ignores the argument AFAICT.
Fixes https://github.com/mesonbuild/meson/issues/2159
* This helps with reproducibility on macOS in the same way
`$ORIGIN` improves reproducibility on Linux-like systems.
* This makes the build-tree more resilient to users injecting
rpaths via `LDFLAGS`. Currently Meson on macOS crashes when
a build-tree rpath and a user-provided `-Wl,-rpath` in
LDFLAGS collide, leading to `install_name_tool` failures.
While this still does not solve the root cause, it makes
the occurrence much less likely, as users will generally
pass absolute `-Wl,-rpath` arguments into Meson.
John Ericson
Dylan Baker
Jussi Pakkanen
Nirbheek Chauhan
Antoine Jacoutot
John Ericson
jml1795
Andrei Alexeyev
Michael Hirsch, Ph.D
Beau Johnston
Daniel Mensinger
Jon Turney
Martin Storsjö
Phillip Cao
Josh Gao
Jan Alexander Steffens (heftig)
pbl
Xavier Claessens
David Seifert
Mohammed Amer Khalidi