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.
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.
We may want to do things like update install scripts as well, which have
to happen before generating the backend. Instead of adding one module
method per thing to do, use a single function that allows for modifying
the Build object directly.
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.
If the optional first "mainlib" argument is there, then we infer several
values. Otherwise, some of those values fall back to a generic default,
and two of them -- name and description -- fall back to being mandatory.
In commit e84f293f67, we removed
validation for description as part of refactoring that never actually
validated anything.
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/
We used to just abort during configure because we ran in-process and
hotdoc's argparse would leak into our own process space. Now we fail to
handle this case and succeed at configuring, only for building to fail
because the hotdoc config file doesn't exist.
We have two copies of this code, and the python module one is vastly
superior, not just because it allows choosing which python executable to
base itself on. Unify this. Fixes various issues including non-Windows
support for sysconfig, and pypy edge cases.
In preparation for wholly merging the dependency handling from the
python module into dependencies.*, move the unique class definitions
from there into their new home in dependencies.python, which is
semantically convenient.
In preparation for handling more work inside dependencies.*, we need to
be able to run a PythonExternalProgram from the python dependency. Move
most of the definition -- but only the parts that have no interest in a
ModuleState -- and subclass a bit of sanity checking that we need to
handle specially when used in the module.
It can go directly inside the function which immediately uses it.
There's no purpose in looking it up exactly once and using it exactly
once, but looking it up outside the function and complicating the
function signature in order to pass it as a function argument.
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
We pass around a PythonInstallation into the depths of the dependency
factory, solely so that we can get at is_pypy in one particular branch.
We don't need the DSL functions, we don't need access to the
interpreter, let's just use the enhanced ExternalProgram object on its
own.
Add is_pypy to the object, and modify other references to get
information from .info['...'] instead of direct access.
This was causing a ninja issue where the native headers were always
being generated because io.github.hse-project.hse_Hse.h was being
expected, but io.github.hse_project.hse_Hse.h was actually generated.
In some cases we'll get an `ImmutableListProtocol[str]` anyway (and
actually, we should probably be getting one in call cases), since we
don't mutate it anyway, just store it as immutable.
Mainly thi sis that `state.find_program()` is annotated incorrectly, it
returns `ExternalProgram | Executable | OverrideProgram`, but it's
annotated to return only `ExteranlProgram`, and thus a bunch of the
annotations in the gnome module are wrong.
It's probably not useful to spam the user with warnings that old
versions of software may not behave correctly when the first warning was
perfectly valid.
There are lots of warnings that become fatal, that are simply unfixable
by the end user. Things like using old versions of software (because
they're using some kind of LTS release), warnings about compilers not
supporting certain kinds of checks, or standards being upgraded due to
skipped implementations (MSVC has c++98 and c++14, but not c++11). None
of these should be fatal, they're informative, and too important to
reduce to notices, but not important enough to stop meson if they're
printed.
Volker Weißmann
Eli Schwartz
MaxHearnden
Charles Brunet
Dylan Baker
Josh Soref
HiPhish
David Seifert
Corentin Noël
Xavier Claessens
Tristan Partin
Peter Urban
Thibault Saunier
X512
Paolo Bonzini
Andreas Deininger