The Python Limited API support that was added in 1.2 had
special handling of Windows, but the condition to check for
Windows was not correct: it checked for MSVC and not for
the target's OS. This causes mingw installations to not have
the special handling applied.
This commit fixes this to check explicitly for Windows.
We do:
```
if is_thing:
assignme = value
if_is_thing:
...
else:
assignme = []
```
It is always defined on both sides, but there was no particular reason
we had to assign it in the later copy. pylint reported it as a false
positive, and it may prove confusing in general, and it's harmless to
move, so do so.
Since it's an implementation detail, and shouldn't be exposed. This also
helps give better error messages when a user writes `import('qt')`,
since otherwise you get an error about `qt doesn't have an initialize
method`, and now you get `qt module doesn't exist`.
Commit 83facb3959 switched to using
`textwrap.dedent` for the code templates for `gnome.mkenums_simple`.
That changed indentation, however, making the generated code harder to
understand.
We improve this by properly indenting the multiline strings before
dedenting them. For optional parameters `decl_decorator` and
`header_prefix`, we add a newline if they are set to keep separation
between generated code blocks.
This way the `rust.bindgen` can generate a second output being a C file,
which contains wrapper functions for static inline ones.
This output file can then be compiled via C targets.
0e7fb07 introduced a subtile bug in the Python module.
If a python version is found, but is missing a required module,
it is added to the list of python installations, but the
`run_bytecompile` attribute for that version was not initialized.
Therefore, if any other python version added something to install, it
was raising a KeyError when trying to read the `run_bytecompile`
attribute for the python version with missing module.
Special notes:
- _nvcc_arch_flags is always called with exact arguments, no need for
default values
- min_driver_version has its args annotation loosened because it has to
fit the constraints of the module interface?
The min_driver_version function has an extensive, informative custom
error message, so leave that in place.
The other two functions didn't have much information there, and it's
fairly evident that the cuda compiler itself is the best thing to have
here. Moreover, there was some fairly gnarly code to validate the
allowed values, which we can greatly simplify by uplifting the
typechecking parts to the dedicated decorators that are both really good
at it, and have nicely formatted error messages complete with reference
to the problematic functions.
It is pretty trivial and more confusing when standalone, especially the
use of a sentinel "unknown" string as a standin for "this isn't one of
the allowed object types". Much easier to directly raise an error in the
fallthrough/else.
It is only ever invoked once. It has a statically known signature based
on how it's used, so there's no good reason to allow it to accept any
defaults -- and defaulting to None messes with type safety.
Saturate is always given, so don't claim it is only sometimes.
It can be a list or a single dependency, but the same logic happens
either way. Instead of manually expanding the logic for both cases, just
convert it to a list as needed.
* Vala: depend on gresources
Valac uses gresource at compile time to look up .ui files
* Automatically pass `--gresourcesdir` to valac
* gnome.compile_resources: clean up duplicate paths better
* Add a test for improved gresouce handling
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
Currently in cross-compilation mode the --host is set to x86-linux-linux,
which results in an error.
Change the code so that for x86 and x86_64 the second part is 'pc',
and 'unknown' for the rest.
Use cpu model instead of cpu family for the first part, as suggested
by @dcbaker
As the result, we get: i386-pc-linux on my setup.
Fixes#12608
Whilst working on the Reproducible Builds effort, we noticed that
meson was generates .pkgconfig files that are not reproducible.
For example, here is neatvnc's pkgconfig file when built with HEAD^1:
Name: neatvnc
Description: A Neat VNC server library
Version: 0.7.0
-Requires.private: pixman-1, aml < 0.4.0, aml >= 0.3.0, zlib, libdrm, libturbojpeg, gnutls, nettle, hogweed, gmp, gbm, libavcodec, libavfilter, libavutil
+Requires.private: pixman-1, aml >= 0.3.0, aml < 0.4.0, zlib, libdrm, libturbojpeg, gnutls, nettle, hogweed, gmp, gbm, libavcodec, libavfilter, libavutil
Libs: -L${libdir} -lneatvnc
Libs.private: -lm
Cflags: -I${includedir}
This is, ultimately, due to iterating over the contents of a set within a
DefaultDict and can thus be fixed by sorting the output immediately prior to
generating the Requires.private string.
An alternative solution would be to place the sorted(…) call a few lines
down:
return ', '.join(sorted(result))
However, this changes the expected ordering of the entire line, and many users
may be unhappy with that (alternative) change as a result. By contrast, this
commit will only enforce an ordering when there are multiple version
requirements (eg. a lower and a higher version requirement, ie. a version
range). It will, additionally, order them with the lower part of the range
first.
This was originally filed (with a slightly different patch) by myself in
the the Debian bug tracker <https://bugs.debian.org/1056117>.
Signed-off-by: Chris Lamb <lamby@debian.org>
If a tool that is looked up in a .pc file is supposed to be there and
has a pkg-config variable entry, but the value is incorrect, we can't
actually use it.
Since commit ab3d02066c we actually do run
the ExternalProgram search procedure on it though -- which caused it to
go wonky and return a None if it doesn't exist, instead of containing a
path to a program that does not exist and fails at build time. This is
better in the case where searching helps resolve .exe file extensions --
and worse in the case where patches to the dependency means nothing we
do is ever enough to actually find what is expected, since now we crash.
Raise an explicit error in such a case, pointing out that the dependency
itself is broken and needs a distributor-side resolution.
Fixes#12412
Regression in commit a3d287c553.
When a given kwarg is not specified, we want to not generate it as a
simd variant. Since the default for buildtarget sources is `[]` it
resulted in building a static library with no sources, and a warning
stating that this was buggy and will eventually be removed.
Fix this by teaching buildtarget sources to allow None, and defaulting
to it specifically for the simd module. We can check this and then skip
processing entirely.
Fixes#12438
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.
Jussi Pakkanen
Andrew McNulty
Eli Schwartz
Tristan Partin
Momtchil Momtchev
Dylan Baker
Matthijs Velsink
Stephan Lachnit
Xavier Claessens
Charles Brunet
Karol Herbst
Ole André Vadla Ravnås
Valeri
Stas Sergeev
Chris Lamb
Chun-wei Fan