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
Partially reverts commit 1624354f33 which
moved a bunch of stuff from strings to enums. The issue here is that
Compiler.mode is not just, or primarily, something we compare, but is
instead written in as e.g. `rule c_{compiler.mode}` to build.ninja, so
this identifier needs to be a string.
Ultimately, the issue is that the commit tried to rewrite a bunch of
things called "mode" that had a couple of TODOs saying to use enums...
but it rewrote everything called "mode" regardless of whether it was a
function kwarg or a compiler property, even though the TODO only applied
to one of them.
Eventually we would probably be better served (to avoid unnecessary
copies) to use the ImmutableListProtocol here, but for the moment this
is effective, it's also what we do in every other case.
We assume /utf-8 for all C builds unless /source-charset or
/execution-charset is specified, but then this will cause trouble for
Visual Studio 2013 or earler since the /utf-8 flag is only supported
since Visual Studio 2015. Specifically, if we try to check whether
compiler flags are supported, those checks will fail since /utf-8 is
never supported on these older Visual Studio versions.
Drop /utf-8 from get_always_args() if we are using Visual Studio 2013
or earlier.
Which adds the `use-set-for-membership` check. It's generally faster in
python to use a set with the `in` keyword, because it's a hash check
instead of a linear walk, this is especially true with strings, where
it's actually O(n^2), one loop over the container, and an inner loop of
the strings (as string comparison works by checking that `a[n] == b[n]`,
in a loop).
Also, I'm tired of complaining about this in reviews, let the tools do
it for me :)
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.
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`.
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.
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.
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.
We have a lot of these. Some of them are harmless, if unidiomatic, such
as `if (condition)`, others are potentially dangerous `assert(...)`, as
`assert(condtion)` works as expected, but `assert(condition, message)`
will result in an assertion that never triggers, as what you're actually
asserting is `bool(tuple[2])`, which will always be true.
* Allow address sanitizer for Visual Studio 2019 version 16.9
Address Sanitizer was first supported with the current syntax in Visual
Studio 16.9.0 (cl version 19.28.29910).
* VS: Convert /fsanitize=address to project file setting
This commit performs some cleanup for the msvc and clang-cl arguments.
* "Disable Debug" (`/Od`) is no longer manually specified for optimization levels {`0`,`g`} (it is already the default for MSVC).
* "Run Time Checking" (`/RTC1`) removed from `debug` buildtype by default
* Clang-CL `debug` buildtype arguments now match MSVC arguments
* There is now no difference between `buildtype` flags and `debug` + `optimization` flags