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
The method can be overridden by setting the `method` key in the wrap
file and always defaults to 'meson'. cmake.subproject() is still needed
in case specific cmake options need to be passed.
This also makes it easier to extend to other methods in the future e.g.
cargo.
Performed using https://github.com/ilevkivskyi/com2ann
This has no actual effect on the codebase as type checkers (still)
support both and negligible effect on runtime performance since
__future__ annotations ameliorates that. Technically, the bytecode would
be bigger for non function-local annotations, of which we have many
either way.
So if it doesn't really matter, why do a large-scale refactor? Simple:
because people keep wanting to, but it's getting nickle-and-dimed. If
we're going to do this we might as well do it consistently in one shot,
using tooling that guarantees repeatability and correctness.
Repeat with:
```
com2ann mesonbuild/
```
On windows, meson would mix posix and windows dir separators in the
computed PACKAGE_RELATIVE_PATH.
Here we force posix directory separator even on Windows. This matches
the CMake behavior and fixes interpretation of the resulting path.
Fixes#6955Fixes#9702
In #11761 it turned out that we failed to correctly handle all
compiler.sizeof API changes in an old commit, breaking use of the
module. And mypy could have caught this for us, except that the module
is neither typed nor checked in CI. Partially solve this by adding lots
of type annotations, greatly reducing the number of mypy errors in this
file from 35 down to 12.
This doesn't accept a dict, only an actual ConfigurationData object. Due
to the way we poke at it, a dict can sort of work anyway, but might not
if the internal layout isn't exactly correct. This is evidenced by the
way we make the dict values be hard-to-read tuples containing emptiness,
because that's how ConfigurationData objects handle descriptions.
Simplify and make the seed dictionary readable, then actually convert it
into a real ConfigurationData. Bonus: this now passes type checking.
It's shorter and more descriptive. Although we always enforce the same
rules either way, a unified decorator is one less line of code for each
location, and also tells you how many "too few" arguments you *did*
pass.
In commit 808d5934dd, compiler.sizeof was
refactored to introduce caching, but cmake subprojects did not adapt to
that API change and ended up embedding the python repr of a tuple as a
cmake variable.
This catches some optimization problems, mostly in the use of `all()`
and `any()`. Basically writing `any([x == 5 for x in f])` vs `any(x == 5
for x in f)` reduces the performance because the entire concrete list
must first be created, then iterated over, while in the second f is
iterated and checked element by element.
Instead of using FeatureNew/FeatureDeprecated in the module.
The goal here is to be able to handle information about modules in a
single place, instead of having to handle it separately. Each module
simply defines some metadata, and then the interpreter handles the rest.
CMake's write_basic_package_version_file has supported since version 3.14
an ARCH_INDEPENDENT option that makes it skip its architecture check in
the Version file.
With this patch Meson now supports it as well, and the change is also
compatible with older CMake versions, as they will simply ignore the
option.
This also slightly changes the contents of the generated Version file
when arch_independent is not set: previously, the if() needed to skip
the arch check was always filled with an empty string, while CMake puts
"FALSE" (or "TRUE") in it. Now, that if() will always be filled with
either "False" or "True", better matching CMake's behaviour.
Whilst working on the Reproducible Builds effort [0], I noticed that meson did
not generate reproducible .cmake files: they include the full path name.
This commit not only makes the build reproducible, but it also matches CMake's
own behaviour. Specifically, CMakePackageConfigHelpers.cmake does the
equivalent transformation using:
get_filename_component(inputFileName "${_inputFile}" NAME)
I originally filed this in Debian as bug #1000327 [1].
[0] https://reproducible-builds.org/
[1] https://bugs.debian.org/1000327
We already have this magic string in mesonlib, and this should always
have used the cmake@ format which is identical to the meson format other
than the regex.
We ended up passing a NoneType as the program binary, which is a very
awkward way to communicate an error when failing to write a basic
package version file.
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.
Custom objects returned by modules must be subclass of ModuleObject and
have the state argument in its methods.
Add MutableModuleObject base class for objects that needs to be deep
copied on assignation.
The only advantage they have is they have the interpreter in arguments,
but it's already available as self.interpreter. We should discourage
usage of the interpreter API and rely on ModuleState object instead in
the future.
This also lift the restriction that a module method cannot add build
targets, but that was not enforced for snippet methods anyway (and some
modules were doing it) and it's really loose restriction as it should
check for many other things if we wanted to make it consistent.
Dependencies is already a large and complicated package without adding
programs to the list. This also allows us to untangle a bit of spaghetti
that we have.