| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
python 3.11 adds a warning that in 3.15, UTF-8 mode will be default.
This is fantastic news, we'd love that. Less fantastic: this warning is
silly, we *want* these checks to be affected. Plus, the recommended
alternative API would (in addition to warning people when UTF-8 mode
removed the problem) also require using a minimum python version of 3.11
(in which the warning was added) or add verbose if/else soup.
The simple, and obvious, approach is to add a warnings filter to hide
it.
|
|
Those classes are used by wrapper scripts and we should not have to
import the rest of mesonlib, build.py, and all their dependencies for
that.
This renames mesonlib/ directory to utils/ and add a mesonlib.py module
that imports everything from utils/ to not have to change `import
mesonlib` everywhere. It allows to import utils.core without importing
the rest of mesonlib.
|
|
Currently it repeats the text of the exception, which appeared
immediately above. And strerror is already part of args, so that was
then doubled. `str(e)` formats this much better anyway.
While we are at it, point out that it is probably a build environment
issue, rather than just saying "this is probably not a meson bug". The
former comes across a bit more as constructive advice rather than just
"idk but it's not our fault".
|
|
In commit fa044e011d5d7a3525c9b3f2acfe1cbf4a0a96a1 we caught OSError and
started emitting a special error message disclaiming that it probably
isn't Meson's fault, and skipping the generic "This is a meson bug and
should be reported" handler.
But, we no longer did this after verifying that the command *isn't*
runpython, so arbitrary scripts that raised OSError would start saying
stuff about Meson, which was wrong.
Start checking for runpython first.
|
|
Mostly just move a comment around back to where it's more relevant, and
handle MESON_FORCE_TRACEBACK once instead of twice.
|
|
In commit 9ed5cfda155c585f7aea896fe2f40d3a92eac43a we refactored
startup to be a bit faster and import less. But this had the side effect
of moving out of our errorhandler. Refactor this so it can be easily
used elsewhere.
|
|
We want to optimize out some internal codepaths used at build time by
avoiding work such as argparse. This doesn't work particularly well when
the argparse arguments are imported before then. Between them, they
indirectly import pretty much all code anywhere, and msetup alone
imports most of it.
Also make sure the regenerate internal script goes directly to msetup.
|
|
Also pass the setup command when rewriting --internal regenerate. This
avoids the issue where `ninja` triggers a reconfigure, and this warning
gets printed as a side effect.
|
|
This is ambiguous, if the build directory has the same name as a
subcommand then we end up running the subcommand. It also means we have
a hard time adding *new* subcommands, because if it is a popular name of
a build directory then suddenly scripts that try to set up a build
directory end up running a subcommand instead.
The fact that we support this at all is a legacy design. Back in the
day, the "meson" program was for setting up a build directory and all
other tools were their own entry points, e.g. `mesontest` or
`mesonconf`. Then in commit fa278f351fe3d6924b4d1961f77b5b4a36e133f8 we
migrated to the subcommand mechanism. So, for backwards compatibility,
we made those tools print a warning and then invoke `meson <tool>`. We
also made the `meson` tool default to setup.
However, we only warned for the other tools whose entry points were
eventually deleted. We never warned for setup itself, we just continued
to silently default to setup if no tool was provided.
`meson setup` has worked since 0.42, which is 5 years old this week.
It's available essentially everywhere. No one needs to use the old
backwards-compatible invocation method, but it continues to drag down
our ability to innovate. Let's finally do what we should have done a
long time ago, and sunset it.
|
|
|
|
|
|
|
|
Some more old style code crept in again.
Additionally, pyupgrade learned to catch more if/elsed code based on the
python version, and delete it.
|
|
msys/python in MSYS2 pretends to be cygwin in all cases for some time
now, so this check was impossible to hit.
The underlying confusion it tried to prevent is still there, namely trying
to build with mingw but wrongly using a msys/cygwin python/meson.
We can use the MSYSTEM env var to detect if we are in a mingw shell, and
in case the Python doesn't match we suggest installing mingw variants of both
python and meson.
Using msys/python + meson in a MSYS environment works fine on the other hand,
so no need to error out in that case.
Fixes #8726
Also addresses the concern raised in
https://github.com/mesonbuild/meson/issues/3653#issuecomment-474122564
|
|
Followup to #10204.
|
|
argparse is the gift that keeps on giving, hahaha. Suppress the script
argument when --version is specified to avoid "required argument not
provided" errors, and print the python version.
The version argument is required in order to make this baseline
functional as a resolved python for find_program, which may specify a
version and expect this to work with python itself. Our incomplete CLI
wrapper over the python CLI interface was missing this.
Fixes #10162
|
|
|
|
This reverts commit e257a870fe5e676c55a2282b0e7fc9be34bba2ac.
The PR adding this command had infinitely hanging CI, and now that it is
merged to master we cannot get any CI on any PR to succeed.
|
|
|
|
Unfortunately, checking for strings without context is exceedingly prone
to false positives, while missing anything that indirectly opens a file.
Python 3.10 has a feature to warn about this though -- and it uses a
runtime check which runs at the same time that the code fails to open
files in the broken Windows locale. Set this up automatically when
running the testsuite.
Sadly, Python's builtin feature to change the warning level, e.g. by
setting EncodingWarning to error at startup, is utterly broken if you
want to limit it to only certain modules. This is tracked in order to be
more efficiently ignored at https://bugs.python.org/issue34624 and
https://github.com/python/cpython/pull/9358
It is also very trigger happy and passing stuff around via environment
variable either messes with the testsuite, or with thirdparty programs
which are implemented in python *such as lots of gnome*, or perhaps
both.
Instead, add runtime code to meson itself, to add a hidden "feature".
In the application source code, running the 'warnings' module, you can
actually get the expected behavior that $PYTHONWARNINGS doesn't have. So
check for a magic testsuite variable every time meson starts up, and if
it does, then go ahead and initialize a warnings filter that makes
EncodingWarning fatal, but *only* when triggered via Meson and not
arbitrary subprocess scripts.
|
|
Do not report a MesonBugException if the command is `runpython`, because
that is 100% other people's code, not ours. It's only used as an
alternative to sys.executable for reporting a path to python, in the
event of a Windows MSI install.
While we are at it, refactor the logic for PermissionError to be a bit
more unified (and sadly use isinstance instead of except, but it is what
it is).
|
|
It's not a MesonBug which needs to be reported, and the existing error
already adequately points out the problematic file.
It is impossible to get a PermissionError for files created by meson
itself, once the build directory has been created, anyway.
|
|
Comment out the pending deprecation notice. It cannot be reached
anymore, but is still useful for the next time we do a version bump.
|
|
|
|
The interpreter tries to catch any exception and add the latest node
information to it, but currently we only used that to print better
formatted error messages on MesonException.
Since we should theoretically have that property for most/all
exceptions, let's percolate that upward, and message the user that an
unexpected traceback was encountered, that it should be reported as a
bug, and the helpful information of "how far into parsing this
meson.build did we get before erroring out, anyway?"
|
|
|
|
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.
|
|
" bat_info = json.loads(bat_json) " may produce error
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc3 ...
Because the vswhere.exe's output is not utf-8 by default
Use UTF-8 encoding for vswhere.exe can fixing it .
|
|
|
|
|
|
|
|
When meson has setup the VS environment, running ninja to build won't
work, user should use meson wrapper to compile.
|
|
|
|
Got the Idea from setuptools
https://github.com/pypa/setuptools/blob/a5131f0b82e098da6c07a03a47f36f3a52f73fb6/setuptools/msvc.py#L176
|
|
|
|
|
|
|
|
|
|
performed by running "pyupgrade --py36-plus" and committing the results
|
|
|
|
This will be printed in bold at the end of interactive meson
sub-commands that won't be parsed by a program. Specifically: setup,
compile, test, and install.
NOTICE: You are using [...]
|
|
|
|
This is tested working with both msbuild and ninja/samu. Since our xcode
support is pretty much broken I didn't bother.
Fixes #6670
|
|
- Typos were found by codespell v1.16.0
|
|
|
|
|
|
|
|
I ran the numbers once before (it's in the meson history) but it's
*much* faster to *not* use len for testing if a container is empty or
not.
|
|
This isn't safe given the way python implements default arguments.
Basically python store a reference to the instance it was passed, and
then if that argument is not provided it uses the default. That means
that two calls to the same function get the same instance, if one of
them mutates that instance every subsequent call that gets the default
will receive the mutated instance. The idiom to this in python is to use
None and replace the None,
def in(value: str, container: Optional[List[str]]) -> boolean:
return src in (container or [])
if there is no chance of mutation it's less code to use or and take
advantage of None being falsy. If you may want to mutate the value
passed in you need a ternary (this example is stupid):
def add(value: str, container: Optional[List[str]]) -> None:
container = container if container is not None else []
container.append(value)
I've used or everywhere I'm sure that the value will not be mutated by
the function and erred toward caution by using ternaries for the rest.
|
|
|
