| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The Interpreter has a method for this, and the module state just wraps
it.
|
|
|
|
Because sometimes we simply need to open code FeatureNew and
FeatureDeprecated checks, but in a re-usable way.
|
|
Since it's also used in the rust module, it should be in a common place.
Also rename from `TEST_KWARGS` to `TEST_KWS`, which is more in line with
the `*_KW` naming scheme used in the type_checking module.
|
|
Due to an accidentally repeated line it would print twice unless
required.
Fixes #8150
|
|
We do some magic to figure out what names of pkg-config dependencies to
even search for. This magic simply checked for `pkg-config` the $PATH
executable, which was broken in a variety of ways and had a comment to
that effect.
|
|
The pkg-config dependency class has some interesting logic for finding a
good pkg-config that will be used for dependency lookups. We sometimes
need to use it, though, outside of the class. Make that possible.
|
|
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 :)
|
|
We already use options.command for the subcommand in use, in this case
devenv. We cannot reuse that variable name for the list of words to
execute inside the devenv.
|
|
When a test executable references a local shared library, make sure that
we apply the appropriate $LD_LIBRARY_PATH so that the linker can find it
at runtime.
The DT_RUNPATH entry does ensure that the binary references the path to
the shared library build, however the RUNPATH list is only searched
after $LD_LIBRARY_PATH. So if the user has a shared library of the same
name in their $LD_LIBRARY_PATH, this will be the version found and used
for running the test. This is bad if you're trying to use Meson to test
a shared library you're developing and have installed in a local prefix
which is under $LD_LIBRARY_PATH.
Fixes #1635
|
|
|
|
|
|
This finds uses of deny-listed functions, which defaults to map and
filter. These functions should be replaced by comprehensions in
idiomatic python because:
1. comprehensions are more heavily optimized and are often faster
2. They avoid the need for lambdas in some cases, which make them
faster
3. you can do the equivalent in one statement rather than two, which
is faster
4. They're easier to read
5. if you need a concrete instance (ie, a list) then you don't have
to convert the iterator to a list afterwards
|
|
|
|
The one case of this was a false-positive, but what we were doing
(checking locals()) is not idiomatic. I've replaced the call to
`locals()` with the obvious `var: T.Optional[str] = None` with check
instead.
|
|
Which catches a very real bug. The zlib system dependency failed to work
on MSVC since initial implementation in commit
c1a3b37ab7e4ccf3a946ee4ba6da81a4c230ecc4 -- it looked for the wrong
name.
|
|
Agrees with Release Notes, Section 1.1, Table 3.
https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html
|
|
The upper bound on the CUDA Compute Capability is not always known.
Avoid checking cuda_hi_limit_gpu_architecture if it remains undefined.
|
|
Co-authored-by: David Seifert <soap@gentoo.org>
|
|
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>
|
|
Fixes #11085
|
|
This is much cleaner than to show a stack trace, where it is hard to
figure out what is going wrong.
|
|
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
|
|
Found with codespell.
|
|
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.
|
|
These are trivially inferred based on their initialized values.
|
|
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 22af56e05aa9cba4740d2ff303d876bb0c3cfb2b,
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
|
|
|
|
|
|
Since commit 32b14b1bb533e10c7344c2e04125a226553c9b9f, 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.
|
|
Mesa is using the rust module in production, so we should stabilize
it.
|
|
Because spaces aren't allowed and result in compilation failures
|
|
When we create a test from a non-executable, we weren't copying the
generated sources, just the static ones.
|
|
Which thinks `sources` should be `List[File]`, but they should be
`List[SourceOutputs]`
|
|
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
|
|
The original version will output something like `xtakes no arguments`, and the modified version will correctly output `x takes no arguments`.
|
|
Since commit 1420d0daceb10cafb52a7405f157032a5cc811a5 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
|
|
|
|
Penalizing users for helping to test unstable modules really makes no
sense. As a fatal warning, users can no longer use
`--fatal-meson-warnings`.
|
|
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.
|
|
- minor cleanups in the vicinity
|
|
Original patch by Helmut Grohne.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023744
|
|
Original patch by Helmut Grohne.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023744
|
|
Use OptionOverrideProxy instead of pure options.
Closes #10393
|
|
|
