In recursive scanning, a script variable was overwritten that caused the
logic *intended* to make the embedded path be trimmed based on $DESTDIR,
to no longer apply. This resulted in embedding the staging path, but
only when install_subdir() was used instead of specifying each file as
the argument to install_sources.
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
Version 2.0 of lcov triggers an error when an exclude pattern is unused. This
can happen when the project has subprojects, but no code in them ends up
covered:
lcov: ERROR: 'exclude' pattern '/[...]/subprojects/*' is unused.
(use "lcov --ignore-errors unused ..." to bypass this error)
So, simply do as it says. Unused patterns doesn't seem problematic (or even
interesting) here, so I don't think there's any risk in simply turning this
off, which matches what happened with earlier versions of lcov anyway.
When a user invokes the scan-build target that Meson generates
all subprojects are included in the resulting report. This commit
modifies the invocation of scan-build to exclude all bugs that
scan-build finds in the subprojects from the final report.
A release note has also been added describing the changed behaviour.
Certain envs may not support invoking itstool by itself directly as a script
as shebang lines are not supported, such as under cmd.exe shells on Windows,
that are normally used for Visual Studio (and the like, such as clang-cl)
builds.
This will call the corresponding interpreter to invoke itstool when needed, so
that itstool can be properly run, even if shebang lines are not supported by
the env.
This will fix building appstream on Windows using clang-cl, for instance.
lcov 2.0 deprecates `--rc lcov_branch_coverage=1` for `--rc branch_coverage=1` and
gives an error when an exclude is used on a non existing directory.
I added a version check for lcov and removed the subprojects directory from the
exclusion list if it does not exist.
Fixes#11995
On python >=3.8, this information is expected to be encoded in the
sysconfig vars.
In distutils, it is always necessary to link to libpython on Windows;
for posix platforms, it depends on the value of LIBPYTHON (which is the
library to link to, possibly the empty string) as generated by
configure.ac and embedded into python.pc and python-config.sh, and then
coded a second time in the distutils python sources.
There are a couple of caveats which have ramifications for Cygwin and
Android:
- python.pc and python-config.sh disagree with distutils when python is
not built shared. In that case, the former act the same as a shared
build, while the latter *never* links to libpython
- python.pc disagrees with python-config.sh and distutils when python is
built shared. The former never links to libpython, while the latter do
The disagreement is resolved in favor of distutils' behavior in all
cases, and python.pc is correct for our purposes on python 3.12; see:
https://github.com/python/cpython/pull/100356https://github.com/python/cpython/pull/100967
Although it was not backported to older releases, Cygwin at least has
always patched in a fix for python.pc, which behavior is now declared
canonical. We can reliably assume it is always correct.
This is the other half of the fix for #7702
Since 3.10.3, Debian finally started patching sysconfig with custom
paths, instead of just distutils. This means we can now go use that
instead. It reduces our reliance on the deprecated distutils module.
Partial fix for #7702
The former is unix-only, which complains when running on the Windows
platform -- even though this code is in a unix-specific branch.
But per the docs:
> As of Python 3.3, this is equivalent to os.chmod(fd, mode).
So we can just use the identical function that is available in more
places.
Add the `clang-tidy-fix` target to apply clang-tidy fixes to the source
code.
This is done by calling `run-clang-tidy` with `-fix` argument.
Add a test case to run `clang-tidy-fix` and verify the file is changed.
Signed-off-by: Lei YU <yulei.sh@bytedance.com>
This commit adds a new keyword arg to extension_module() that enables
a user to target the Python Limited API, declaring the version of the
limited API that they wish to target.
Two new unittests have been added to test this functionality.
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/
```
We support this in a machine file:
```
[binaries]
pkgconfig = 'pkg-config'
pkg-config = 'pkg-config'
```
and you can use either one, because internally we look up both. If you
only set *one* of them, this plays awkwardly with setting $PKG_CONFIG,
since we don't know which one you set in the machine file and the
*other* one will be initialized from the environment instead.
In commit 22df45a319 we changed program
lookup of config-tool style dependencies to use the regular tool names
and only fall back on the strange internal names. This affected the
pkg-config class too.
The result is that instead of preferring `pkgconfig =` followed by
$PKG_CONFIG followed by `pkg-config =`, we inverted the lookup order.
This is a good idea anyway, because now it behaves consistently with
`find_program('pkg-config')`.
Unfortunately, we documented the wrong name in a bunch of places, and
also used the wrong name in various testsuite bits, which meant that if
you set $PKG_CONFIG and then ran the testsuite, it would fail.
Correct these references, because they are buggy.
One test case expected to find_program() a native copy for convenience
of testing against natively installed glib. Force it to resolve a native
copy.
For all source `*.py` files installed via either py.install_sources() or
an `install_dir: py.get_install_dir()`, produce `*.pyc` files at install
time. Controllable via a module option.
When devhelp is enabled, hotdoc generates a devhelp/ subdir that needs
to be installed to /usr/share/devhelp/. Otherwise, the html/ subdir
needs to be installed to /usr/share/doc/<project>/html/
It seems this happens because at some point setuptools imports gettext,
and we have a script by the same name.
In general, this path injection by default is bad news for our use case.
Python 3.11 introduced -P for this reason, but we cannot depend on that.
Instead, check for it first, and delete it, before doing more imports.
The version lookup should be silent. While we're at it, the version
lookup should not be happening more than once, which printing multiple
messages indicated we were doing. Pass the version into the per-file
function rather than looking it up fresh each time.
Fixes https://github.com/mesonbuild/meson/pull/11054#issuecomment-1430169280
We write this out as an embedded string to a tempfile in order to run
it, which is pretty awkward. And usually Meson's files are already files
on disk, not packed into a zip, so we can simply run it directly. Since
python 3.7, which is our new minimum, we can handle this well via the
stdlib. (There's also mesonbuild.mesondata, but we do not need
persistence in the builddir.)
This also solves the problem that has always been there, of giant python
programs inside strings occasionally confusing syntax highlighters. Or
even, it would be nice if we had syntax highlighting for this
introspection program. :D
Given the construct `foo = (bar == baz)` some people like parentheses
and some do not. They're pointless and don't mean anything, though. I
don't feel this is particularly helpful to code clarity, tbh, and pylint
now notices this and warns about it in our current pylint config.
I think this is reasonable, so let's remove the odd parens.
fix_jar() tries to remove an existing Class-Path entry from the jar
manifest by postprocessing the manifest and passing it to `jar -um`.
However, `jar -um` can only add/replace manifest entries, not remove
them, and it also complains loudly when replacing an entry:
Dec 13, 2022 7:11:19 PM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Manifest-Version.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
Thus fix_jar() produces one such warning for each entry in the manifest
and accomplishes nothing else.
Use jar -uM instead. This completely removes the manifest from the jar
and allows adding it back as a normal zip member, fixing fix_jar() and
avoiding the warnings.
Fixes: https://github.com/mesonbuild/meson/issues/10491
Fixes: c70a051e93 ("java: remove manifest classpath from installed jar")
Due to a deficiency in upstream clang-format, our automatic target for
`ninja clang-format-check` runs clang-format, then compares the bytes of
the file before and after to see if anything changed. If it did change,
we rewrite the file back to its original form and error out.
Since clang-format 10, there is an option to report warnings instead of
writing the reformatted file, and also, to make those warnings fatal.
This is a much better user experience, to see *what* is wrong, not just
that something is wrong, and also gets rid of a pretty gross "modify
your files when you didn't ask for it" behavior that is vulnerable to
getting interrupted.
Let's switch over to the new approach, if we can.
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 :)