This is a no-op change from v2 to v3, but github complains that nodejs
is outdated if you don't. It's not obvious why this required a major
version bump...
However, half of our uses are on v1, which has a decent fix: failure to
upload artifacts constitutes a step failure.
Not much changes, really, other than it now sets PKG_CONFIG_PATH to
point to the python it just installed. This should generally not be a
problem (Meson's python module sets that anyway based on the
executable's introspection data).
Add a MissingCompiler class returned by compiler detecting methods
intead of None - accessing such an object raises a DependencyException
Fixes#10586
Co-authored-by: duckflyer <duckflyer@gmail.com>
lgtm.com was acquired by github. It is deprecated and on its way out,
because they've integrated the functionality itself into github. Take a
look at what its official replacement can do.
This does run as yet another Actions slot, which is already fairly
excessive, but the average runtime seems about 5 minutes so that's not
too bad...
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.
"meson setup" ignores unused compiler options, like "cpp_args" on a project without C++.
"meson configure" doesn't have the filtering from "set_default_options", so it fails with :
ERROR: Unknown options: "cpp_args"
So now unused compiler options (ie not in coredata.options) are no longer marked unknown.
Fixes: #11060
flake8 6 upgrades to pyflakes 3, and in turn this means that support for
parsing `# type: ` style annotations has been removed.
https://github.com/PyCQA/pyflakes/pull/684
This caused one file to fail linting, because it had a typing import
which was only used by a type comment.
```
mesonbuild/cmake/interpreter.py:55:5: F401 '.common.CMakeConfiguration' imported but unused
```
Updating it to actual annotations allows pyflakes to detect its usage
again, and flake8 passes. Do the whole file while we are here.
The `py.dependency(embed: false)` method is supposed to consistently
provide a distutils-like `python.pc` / `python-embed.pc` interface
regardless of Python version. It handles both pkg-config and sysconfig
scraping. For the latter, we respect the value of self.link_libpython
as determined by distutils, and construct a fully custom dependency. For
the former, we blindly assume pkg-config is correct.
It isn't correct, not until Python 3.8 when embed was added. Before
then, we need to process the pkg-config dependency based on
link_libpython. We did this, but only inside the extension_module
method, which is obviously wrong.
Delete the special casing from extension_module, and handle it inside
the dependency.
Fixes#11097
On Windows, in Python version prior to 3.8.7, the `sysconfig` modules
provides an extension filename suffix that disagrees the one returned
by `distutils.sysconfig`. Get the more awesome suffix from the latter
when building for a Python version known to present this issue.
Simplify the extension module filename suffix lookup to use the same
method used by `setuptools`.
Adjust project tests accordingly.
Fixes#10960.
-Wnon-virtual-dtor is not what people think of as a standard warning
flag. It was previously removed from -Wall in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16190 on the grounds that
people didn't like it and were refusing to use -Wall at all because it
forced this warning. Instead, it is enabled by -Weffc++ which is
typically not enabled and even comes with GCC documentation warnings
stating that the standard library doesn't obey it, and you might need to
`grep -v` and filter out warnings. (!!!)
It doesn't fit into the typical semantics of Meson's warning_level
option, which usually aligns with compiler standard warning levels
rather than a niche ideological warning level.
It was originally added in commit 22af56e05a,
but without any specific rationale included, and has gone unquestioned
since then -- except by the Meson users who see it, assume there is a
finely crafted design behind it, and quietly opt out by rolling their own
warning options with `add_project_arguments('-Wall', ...)`.
Furthermore a GCC component maintainer for the C++ standard library
opened a Meson bug report specially to tell us that this warning flag is
a "dumb option" and "broken by design" and "doesn't warn about the right
thing anyway", thus it should not be used. This is a reasonably
authoritative source that maybe, just maybe, this flag... is too
opinionated to force upon Meson users without recourse. It's gone beyond
opinionated and into the realm of compiler vendors seem to think that
the state of the language would be better if the flag did not exist at
all, whether default or not.
Fixes#11096
Factors out opening the meson log into its own function so that
it can be used in the places where with was done before.
Additionally instead of checking if the file exists before opening it,
try to open it and handle the exception when it is not found.
It was impossible to specify null arguments in the exclude array,
while they were passed properly in the code, they were stringified
while the entries in the options array were just completely removed.
To fix this, do not early stringify the argument name and option
together as that would make it impossible to properly match it to
None without introducing a new special case for the string "None".
So instead they are now kept as tuples and only stringified when
its actually needed.
Since commit 32b14b1bb5, hotdoc is run
during configure as an external program. It turns out though, that in
some cases we passed NoneType in the cmd array, previously to
hotdoc.run_hotdoc.run() and now via subprocesses. The former "worked"
due to ignoring unknown arguments (?) but the latter was broken because
command line interfaces don't accept python NoneType objects, naturally.
End result: when for example building Meson's own documentation, this
fails with a python traceback.
The reason this happens to begin with turns out to be, once again,
because of the legacy debt of homebrewed kwargs parsing. We have a
function for `process_known_args` that handles args and ignores them if
they are NoneType, and then include_paths is handled via a custom
processor that internally adds them, then returns a *list* of NoneType
which then gets appended to the global cmd, because the logic ends up as
`[None, None] is None` which is a failed check, so we go ahead and add
it.
It's odd that we ever attempted to process it twice to begin with, so
let's simply not do that.
We are just using this dictionary to get keys, and we could also just
set it ourselves but with None values. But we have a code abstraction
for this already; use it.
We use a dummy project with a vague name and try to find flags for it
based on the installable pkg-config files. This sort of works,
generally, because it attempts to match `-lct` which doesn't exist
because the test case isn't installed, and that link argument is passed
directly through.
Except, sometimes that library does exist. It is provided by the
"freetds" project, which may be a dependency other tools. In that case,
Meson finds a library, and the `dependency()` resolves to
`/usr/lib/libct.so` and the test fails.
Fortunately, we do have an API to say that we really want to get back
the same flags pkg-config returned. Use this.
We test a couple ways of running the meson command, and double check
that the debug logs record the meson command used (including python).
But when running the meson command as an executable instead of as a
python script, we see whichever version `env` in the shebang sees.
Fix this by mocking the python command as well.
*.qrc files converted to C++ sources could make use of Qt headers, and
in practice for qt4 they seem to. Since this is Qt code to begin with,
it makes sense to depend on the Qt being targeted regardless of version.
We need to run it as an external command at build time anyway, and we
detect it by looking it up as an ExternalProgram. It seems odd to then
import it into Meson's python interpreter and run the main function.
Moreover, this errors out when you are running two different pythons,
one for Meson and one for hotdoc. For example, when hotdoc is installed
normally, but you're testing Meson against a nondefault newer version of
python.
We have divergent implementations of loading a pickled *.dat file. The
Build class loader has a better error message. But the generic loader
handles TypeError and ModuleNotFoundError. Merge the implementations,
and use it for Build as well.
Fixes#11051
Since commit 1420d0dace we use coredata's
cmd_line.txt handler to get the right setup arguments. But there's a bug
in that -- it mishandles cross/native files, producing invalid
descriptions of the command line. The only other place this was used,
though, is when generating meson-log.txt.
Fix it to produce correctly formatted arguments.
Fixes#10980
The coverage report was always the final section of the main test run.
This made it hard to scroll around and find exactly what went wrong --
particularly as not everyone realizes that coverage isn't part of the
test run, but also because the output from coverage is... excessively
long.
This mirrors what we do in our other workflows.
The system linkers don't support this particular GNU extension on
these OS'es, so don't build them there.
Based on an OpenIndiana patch created by @alarcher. Closes#9882.
In a couple of python module tests, we try to test things that rely on
the default python being the same one we look up in the python module.
This is unsolvable for the deprecated python3 module, as it actually
uses the in-process version of python for everything. For the python
module, we could actually look up the default system python instead of
the one we are running with, but then we wouldn't be testing the
functionality of that alternative python... and also the install
manifest tests would see files installed for the wrong version of
python, and report a combination of missing+extra files...
Solve both tests by just skipping the parts we cannot check.
- qt5 -> qt6
- remove version information from when the Qt6 module was not a thing
- linked to dependency function
- highlight version information with *...* and placing it at the front of options or on new lines in text
- reformatted for shorter lines
Olexa Bilaniuk
Eli Schwartz
SmallWood-D
Axel Ricard
Marvin Scholz
David Robillard
Loïc Yhuel
Daniele Nicolodi
Jussi Pakkanen
Dylan Baker
Zihua Wu
Xeonacid
Xavier Claessens
Tristan Partin
Alan Coopersmith
tastytea
Hagen Möbius
Ralf Gommers