Caching Compiler.run() seems likely to cause problems, but some users, like
.sizeof(), we know enough about the program run to make it safe.
This commit just adds the Compiler.cached_run(), a subsequent commit makes use
of it.
ccache was used in all command lines but disabled using CCACHE_DISABLE
in Compiler.compile() method. Wrapping invokations still has a cost,
especially on Windows.
With sccache things are even worse because CCACHE_DISABLE was not
respected at all, making configure *extremely* slow on Windows when
sccache is installed.
https://github.com/mesonbuild/meson/pull/9287 changed the `optimization=0`
to pass `-O0` to the compiler. This change is reasonable by itself
but unfortunately, it breaks `buildtype=plain`, which promises
that “no extra build flags are used”.
`buildtype=plain` is important for distros like NixOS,
which manage compiler flags for optimization and hardening
themselves.
Let’s introduce a new optimization level that does nothing
and set it as the default for `buildtype=plain`.
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.
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.
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
[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>
It is always used as an immutable view so there is no point in doing
copies. However, mypy insist it must implement the same APIs as
Dict[OptionKey, UserOption[Any]] so keep faking it.
This should be done in all cases of language_stdlib_only_link_flags, but
I don't have access to all of the compilers to test it.
This is required in cases where object files created by gfortran are
linked using another compiler with a differen default search path, such
as gfortran and clang together.
Allow using the links method to test that the C++ driver (e.g. g++) can be used to
link C objects. One usecase is that the C compiler's libsanitizer might not be
compatible with the one included by the C++ driver.
This is theoretically backwards-incompatible, but it should be treated as a
bugfix in my opinion. There is no way in Meson to compile a .c file with the
C++ driver as part of a build target, therefore there would be no reason to
do something like meson.get_compiler(meson.get_compiler('cpp').links(files('main.c')).
Fixes: #7703
In some cases, link tests would like to use objects provided by a compiler
for a different language, for example linking a C object file with a C++
compiler. This kind of scenario is what link_language is for, but it is
impossible to test that it works with a linker test.
This patch implements the required support in the Compiler class. The
source code compiler is passed to the Compiler.links method as an
argument.
* compilers: improve docstring to `get_compiler_check_args()`
There was an incomplete list, which wasn't useful as it now takes an
enum anyway. Also add a new entry to the list of reasons to use this
function.
* clang: Add -Werror=implicit-function-declarations to check_args
Unlike GCC, clang warns but doesn't error when an implicit function
declaration happens. This means in checks like
`compiler.has_header_symbol('string.h', 'strlcat')` (on Linux, at least)
that GCC will fail, as there is no such function; clang will emit a
warning, but since it exists with a 0 status Meson interprets that as
success. To fix this, add `-Werror=implicit-function-declarations` to
clang's check arguments.
There seems to be something specific about functions that _may_ exist in
a header on a given system, as `cc.has_header_symbol('string.h',
'foobar')` will return false with clang, but `strlcat` will return true,
even though it's not defined. It is however, defined in some OSes, like
Solaris and the BSDs.
Fixes#9140
There are two changes here, one is to remove an `elif` that is
effectively an `else`, that helps the type checker and provides a small
speedup potentially. The second is a potentially unbound variable, that
currently isn't hit, but very much could be.
Josh Soref
Renan Lavarec
Charles Brunet
Andres Freund
mtribiere
Xavier Claessens
Eli Schwartz
Tatsuyuki Ishi
Jan Tojnar
Marco Trevisan (Treviño)
Dylan Baker
Fini Jastrow
Christian Clauss
Paolo Bonzini
Jussi Pakkanen
Daniel Mensinger
Justin Handville