This used to be fine, until imports were removed from this file. Now a
function annotated as T.NoReturn doesn't actually tell mypy that it
cannot return, though, so we manually do it.
We no longer need these upfront at all, since we now import the ones we
need for the language we are detecting, at the time of actual detection.
This avoids importing 28 files, consisting of just under 9,000 lines of
code, at interpreter startup. Now, it is only imported depending on
which languages are invoked by add_languages, which may not even be
anything. And even if we do end up importing a fair chunk of it for
C/C++ projects, spreading the import cost around the interpreter runtime
helps responsiveness.
Only import the ones we need for the language we are detecting, once we
actually detect that language.
This will allow finally dropping the main imports of these files in a
followup commit.
Instead of comparing against specific compiler classes, check the
logical compiler id or language etc.
In a couple cases, we seem to be missing a couple things by being a bit
too strict about the exact class type.
This is wasteful and generally unneeded, since code can just use the
compiler they detected instead of manually poking at the internals of
this subpackage.
It also avoids importing an absolute ton of code the instant one runs
`from . import compilers`
In commit d326c87fe2 we added a special
holder object for cached compilation results, with some broken
attributes:
- "command", that was never set, but used to print the log
- "args", that was set to some, but not all, of the information a fresh
compilation would log, but never used
Remove the useless args attribute, call it command, and use it properly.
We compared a Visual Studio (the IDE) version, but we wanted a MSVC (the
compiler) version. This caused the option to be passed for a few too
many versions of MSVC, and emit a "D9002 : ignoring unknown option" on
those systems.
Compare the correct version using the version mapping from
https://walbourn.github.io/vs-2017-15-7-update/Fixes#10787
Co-authored-by: CorrodedCoder <38778644+CorrodedCoder@users.noreply.github.com>
Meson internally knows about many languages and tools, and *FLAGS
variables, and which languages to use them for. Instead of duplicating
this logic, import it from mesonbuild.*
This logic was originally standalone, but now that it is merged into the
Meson tree we can have a single source of truth.
If this command fails, for example when CXX is something not generic
enough to be a valid universal compiler command (clang -std=c++11
perhaps), we end up with two problems:
- it's impossible to figure out what Meson ran to get that error
- the error report isn't clear on what is stdout and what is stderr, or
even that that is what the message is about.
```
meson.build:1:0: ERROR: Unable to get clang pre-processor defines:
error: invalid argument '-std=c++11' not allowed with 'C'
```
What's C doing there and why is Meson talking about it? Answer: that's
compiler stdout. Say so.
We do something similar when running get_compiler() method checks from
the DSL. This ensures that if errors happen, the log file we tell people
to check actually works.
Specifically, this is a combination of the following:
- Revert "visualstudio.py: Apply /utf-8 only on clang or VS2015+"
This reverts commit 6e7c3efa79.
- Revert "Visual Studio: Only use /utf-8 on VS2015 or later or clang-cl"
This reverts commit 8ed151bbd7.
The changes were broken and untested, although this is because of a lack
of general CI testing for all languages on Windows. At least, this broke
the use of ifort, and possibly more.
The changes are fundamentally a bit "exciting", as they step out of the
hierarchy of compiler definitions and apply arguments almost willy-nilly.
And apparently it's leaky all over the place. I don't understand all of
what is going on with it, but it plainly failed to achieve its desired
goal and needs to be rolled back ASAP.
Transpilers need to run on the build machine in order to generate their
output, which can then be taken by a cross-compiler to create the final
output.
MachineChoice is a mesonlib object, not a compilers object, so it makes
no sense to import it from the latter simply because the latter imports
it too. This results in brittle module dependencies and everything
breaking when a refactor removes it from the latter.
... also it is a typing-only import so while we are fixing it to import
from the right place, we can also put it in a type-checking block.
In PR 10263, we didn't account for that we may have initialize the Visual
Studio-like compiler two times, once for a C compiler and once for the
C++ compiler, so we end up with Meson breaking on Visual Studio 2013
or earlier, such as when building GLib.
Fix this by setting up the always_args member of
the VisualStudioLikeCompiler instance during __init__() as needed, so that
we avoid falling into modifying shared objects.
Leak sanitizer can be enabled without the whole AddressSanitizer, this
can be done by passing -fsanitize=leak as documented at [1].
Meson doesn't support this, so add support for it.
[1] https://clang.llvm.org/docs/LeakSanitizer.html
This option is only valid for C++ and ObjC++, but the kwarg is useful
for mixed language targets. Asking for inlines as well, when the
compiler driver is trying to build the C components of a target, results
in gcc emitting:
```
cc1: warning: command-line option ‘-fvisibility-inlines-hidden’ is valid for C++/ObjC++ but not for C
```
Squelch this warning by filtering it out on Meson's side of things.
Otherwise it always returns the value for c++98, starting with MSVC 2017
15.7 or later. Earlier versions are not affected by this mis-feature.
See: https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-160
This was originally applied as 0b97d58548
but later reverted because it made the CI red. Try it again, now.
Original-patch-by: Dylan Baker <dylan@pnwbakers.com>
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
[why]
Support for the relatively new mold linker is missing. If someone wants
to use mold as linker `LDFLAGS="-B/path/to/mold"` has to be added instead
of the usual `CC_LD=mold meson ...` or `CXX_LD=mold meson ...`.
[how]
Allow `mold' as linker for clang and newer GCC versions (that versions
that have support).
The error message can be a bit off, because it is generic for all GNU
like compilers, but I guess that is ok. (i.e. 'mold' is not listed as
possible linker, even if it would be possible for the given compiler.)
[note]
GCC Version 12.0.1 is not sufficient to say `mold` is supported. The
expected release with support will be 12.1.0.
On the other hand people that use the un-released 12.0.1 will probably
have built it from trunk. Allowing 12.0.1 is helping bleeding edge
developers to use mold in Meson already now.
Fixes: #9072
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
The compiler flag only exists on Visual Studio 2015 or later, or clang-cl,
and using this always can interfere with compiler feature detection when
this flag is not supported.
So, remove '/utf-8' from always_args if we are on Visual Studio 2013 or
earlier.
This has been broken ever since the original implementation. Due to a
typo, the optimization flag used a zero instead of an uppercase "o",
which the compiler then breaks on during argument parsing because it is
an invalid argument.
Fixes#10267
When something goes wrong with running the compiler in
_symbols_have_underscore_prefix_searchbin, print stderr instead,
as it actually contains helpful output while stdout is usually empty
in this case.
Eli Schwartz
Dylan Baker
Yang Bo
Alf Henrik Sauge
Justin Blanchard
Tristan Partin
Chun-wei Fan
Stepan Nassyr
Marco Trevisan (Treviño)
Andreas Obergschwandtner
Khairul Azhar Kasmiran
Remi Thebault
Fini Jastrow
Marvin Scholz