| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This adds support for DEF files to rust and removes
some hasattr duck typing.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
|
|
|
|
I've done the compile and link flags in one commit since they're so
closely related
|
|
|
|
1. Generate OMF objs with `-Zomf' compiler flags
2. Generate OMF libs with `.lib' suffix using `emxomfar' as a librarian
|
|
|
|
The Rust compiler will need these to check the rust_nightly option.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
GCC 15 supports incremental LTO (caching). It's the same feature as
Clang's ThinLTO caching.
Unfortunately, for the Clang ThinLTO cache support, we chose a pretty
vendor-specific option name, and I don't want to worry about deprecating
that (-Db_thinlto_cache and -Db_thinlto_cache_dir) at this time, so...
Wire -Db_thinlto_cache and -Db_thinlto_cache_dir for GCC in the obvious
and natural way.
Other notes:
* GCC, unlike Clang, requires the cache dir to exist. If the
user passes an invalid directory, that's on them, but for our default
in meson-private, we should os.mkdir() it, so we do that now too.
* I did wonder about adding -flto-partition=cache, but when I asked about
this last year [0], the response was that it has too many caveats. Though
Honza did recently [1] suggest it has some utility, so I don't know. I'll
ask about it.
[0] https://inbox.sourceware.org/gcc-patches/vjeanwm7b2jnedzmbwww4cy6jf4prty6ypxvz7x5d463xw2mys@bxzxuvgfaplf/
[1] https://inbox.sourceware.org/gcc-patches/aLnAGpln6SXbjV7e@kam.mff.cuni.cz/
Closes: https://github.com/mesonbuild/meson/issues/14428
|
|
Stop early-returning as we're going to do more work in this function
shortly for incremental LTO.
Bug: https://github.com/mesonbuild/meson/issues/14428
|
|
... by calling self.get_lto_compile_args, as we expect the same arguments
to be passed at both compile-time and link-time, and we're doing the exact
same procedure to determine -flto=XXX.
Bug: https://github.com/mesonbuild/meson/issues/9536
|
|
Without this, we pass (say) `-flto=auto` at compile-time, but just `-flto`
at link-time.
See also https://gcc.gnu.org/PR114655 and the linked r12-824-g3cbcb5d0cfcd17,
i.e. before GCC 12, we'd end up linking with 1 job.
The clang mixin looks correct already.
Closes: https://github.com/mesonbuild/meson/issues/9536
|
|
Replace the hardcoded version strings with class attributes to allow
subclasses to override them.
|
|
Signed-off-by: Kushal Pal <kushpal@qti.qualcomm.com>
|
|
|
|
|
|
In the preceding commit we have started to perform compiler checks for
the value of `b_sanitize`, which allows us to detect sanitizers that
aren't supported by the compiler toolchain. But we haven't yet loosened
the option itself to accept arbitrary values, so until now it's still
only possible to pass sanitizer combinations known by Meson, which is
quite restrictive.
Lift that restriction by adapting the `b_sanitize` option to become a
free-form array. Like this, users can pass whatever combination of
comma-separated sanitizers to Meson, which will then figure out whether
that combination is supported via the compiler checks. This lifts a
couple of restrictions and makes the supporting infrastructure way more
future proof.
A couple of notes regarding backwards compatibility:
- All previous values of `b_sanitize` will remain valid as the syntax
for free-form array values and valid combo choices is the same. We
also treat 'none' specially so that we know to convert it into an
empty array.
- Even though the option has been converted into a free-form array,
callers of `get_option('b_sanitize')` continue to get a string as
value. We may eventually want to introduce a kwarg to alter this
behaviour, but for now it is expected to be good enough for most use
cases.
Fixes #8283
Fixes #7761
Fixes #5154
Fixes #1582
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
|
|
So we can re-use it in the ObjC++ standards
|
|
So we can re-use it for the ObjC code
|
|
This inclusion was a misunderstanding on my part: this warning isn't generally
applicable to standard C (it prevents using double literals whatsoever since C
doesn't have a suffix for them), but exists to support a GNU C extension. It
also has no counterpart in clang. So, remove it, since
warning_level=everything doesn't include such things.
|
|
|
|
It is useful to apply a limit to the number of processes even outside "meson test",
and specifically for clang tools. In preparation for this, generalize
determine_worker_count() to accept a variable MESON_NUM_PROCESSES instead of
MESON_TESTTHREADS, and use it throughout instead of multiprocessing.cpu_count().
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
version_compare can take a few milliseconds. If you have a thousand object files
or a multiple thereof, it adds up.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
|
|
This allows to get this fixed value before the class is initialized.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
|
|
|
|
This will be needed by the Apple compiler
|
|
|
|
|
|
|
|
This is a first step to make `buildtype` a true alias of `debug` and
`optimization` options.
See #10808.
Relates to:
- #11645
- #12096
- #5920
- #5814
- #8220
- #8493
- #9540
- #10487
- #12265
- #8308
- #8214
- #7194
- #11732
|
|
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
|
|
Since it's deprecated anyway, we don't really want to plumb it all the
way down into the build and backend layers. Instead, we can just turn
it into a `win_subsystem` value in the interpreter if `win_subsystem`
isn't already set.
|
|
Names and types of some methods did not match their parent methods.
|
|
Although mypy wasn't complaining, pyright was.
|
|
|
|
There were a ton of naked strings with TODOs telling us to use the enum.
|
|
Fixes: #11940
|
|
docs: gcc https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html
scons: https://scons.org/doc/3.0.5/HTML/scons-user/apb.html
.S Windows: assembly language file
ARM: CodeSourcery Sourcery Lite
.sx assembly language file + C pre-processor
POSIX: assembly language file + C pre-processor
|
|
This option was introduced with GCC 8.1.0 as in the original commit, but the
value wasn't right initially and was volatile during the 8 series.
To avoid this, this commit moves the warning to 9.1.0 (the next version we
generally care about), since we don't want to get too deep into the weeds of
point releases, and a warning not being used yet in some particular version of
GCC isn't a big deal.
|
|
clang++ main.cpp -fprofile-correction
clang-15: warning: optimization flag '-fprofile-correction' is not supported
[-Wignored-optimization-argument]
|
|
|
|
Adds a new maximum warning level that is roughly equivalent to "all warnings".
This adds a way to use `/Wall` with MSVC (without the previous broken warning),
`-Weverything` with clang, and almost all general warnings in GCC with
strictness roughly equivalent to clang's `-Weverything`.
The GCC case must be implemented by meson since GCC doesn't provide a similar
option. To avoid maintenance headaches for meson, this warning level is
defined objectively: all warnings are included except those that require
specific values or are specific to particular language revisions. This warning
level is mainly intended for new code, and it is expected (nearly guaranteed)
that projects will need to add some suppressions to build cleanly with it.
More commonly, it's just a handy way to occasionally take a look at what
warnings are present with some compiler, in case anything interesting shows up
you might want to enable in general.
Since the warnings enabled at this level are inherently unstable with respect
to compiler versions, it is intended for use by developers and not to be set as
the default.
|
|
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`.
|
|
compilers
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.
|
|
[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>
|
|
Fixes the following ResourceWarnings:
ResourceWarning: subprocess 25556 is still running
_warn("subprocess %s is still running" % self.pid,
ResourceWarning: Enable tracemalloc to get the object allocation traceback
mesonbuild/compilers/mixins/gnu.py:195: ResourceWarning: unclosed file <_io.BufferedReader name=4>
return gnulike_default_include_dirs(tuple(self.exelist), self.language).copy()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
|
