That method had nothing specific to the backend, it's purely a Target
method. This allows to cache the OptionOverrideProxy object on the
Target instance instead of creating a new one for each option lookup.
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
In commit 68e684d51f the function
signature was changed, but several places did not adapt. Additionally,
we now totally dropped the in-place update of gtkdoc's sole source of
dependencies, but didn't propagate them upward to assign the newly
collected dependencies anywhere.
Fixes building gtkdoc with internal dependencies and failing when
specified directly (when building the 'all' target with sufficiently
random parallelism, deps may be built on time).
Fixes:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008382https://gitlab.gnome.org/GNOME/libmediaart/-/issues/4
We currently inconsistently handle connection, `has_ssl`, and printing
errors on urlopen failure between `meson subprojects` and `meson wrap`.
Make the latter work more like the former.
We have a fallback route in `meson subprojects download` and friends,
which tries to retrieve wrapdb urls via http, if Python was not built
with SSL support.
Stop doing this. Replace it with a command line option to specify that
insecure downloads are wanted, and reference it in the error message if
downloading fails due to SSL issues.
Due to https://github.com/gcovr/gcovr/pull/576 it is not possible to
`pip install gcovr` and have it work.
It is possible, but not ideal, to install the cygwin gcovr package,
which is unmaintained and built for python36 while only depending on
python39.
This is of course not a problem on the other CI jobs, where we either
install it from a distro repository that ensures it is stable and
backports patches, or simply tests that the resulting image passes tests
before baking it as a CI images update.
gcovr upstream isn't sure when they are going to release a new version
that fixes this bug. There is a new feature release scheduled "soon".
In case a link is pointing_to an absolute path and we are using $DESTDIR
we fail in case the target is missing.
This is incorrect because we may need to use an absolute path to an
already installed file that is in $DESTDIR.
So if an absolute target is not existing, check if we have such file in
$DESTDIR before failing for real.
There is no need to go through all sources again, we already did that to
populate self.compilers. When cs or java compilers are in the list, then
there must be only one compiler.
The code was also not considering generate sources any way.
Previously subprojects inherited languages already added by main
project, or any previous subproject. This change to have a list of
compilers per interpreters, which means that if a subproject does not
add 'c' language it won't be able to compile .c files any more, even if
main project added the 'c' language.
This delays processing list of compilers until the interpreter adds the
BuildTarget into its list of targets. That way the interpreter can add
missing languages instead of duplicating that logic into BuildTarget for
the cython case.
Commit a0cade8f introduced a typo and wrongly check for
gtk4-update-icon-cache twice.
If gtk4-update-icon-cache (gtk4) is not found, look for
gtk-update-icon-cache (gtk3) instead.
Looks like boost dependency mixes up it's compiler and linker argument
order when it is removing duplicates (?) from those. This causes
unnecessary recompilations of everything depending on those components.
Use OrderedSet to remove the duplicates while also maintaining
consistent order for them.
- fix the research of target built by DUB
- explicitely state that DUB dynamic libraries and source libraries are not supported (yet) (mesonbuild#6581)
- fix the build settings of recipes having sub-dependencies (mesonbuild#7560)
- fix winlibs added from dub recipe
- sanitization, comments, explanations...
We print a warning if a compilation database isn't successfully
generated, which is good, because that gives some visibility in case the
user really wanted to use the compdb. But warnings default to being
fatal with --fatal-meson-warnings, which is not so good, because this
isn't a very important warning at all, and we'd rather not error out in
such cases when building works fine and a random bonus IDE feature
doesn't work.
Mark this particular warning as non-fatal.
Fixes side issue in https://github.com/mesonbuild/wrapdb/pull/343#issuecomment-1074545609
It is always used as an immutable view so there is no point in doing
copies. However, mypy insist it must implement the same APIs as
Dict[OptionKey, UserOption[Any]] so keep faking it.
It looks like internally we use pkgconfig, even though the installed
name is pkg-config. This fixes `tests cases/common/44 pkgconfig-gen`,
which will ignore PKG_CONFIG and select the wrong pkg-config binary if
you have $PKG_CONFIG set.
If you rely on PKG_CONFIG_PATH to make anything work (like nixos) then
these tests cannot pass without the system values appended to the
override values.
In the even that all of the inputs are generated, and they're all
generated into the same folder, and there are no subfolders, we would
fail to correctly handle all of the files after the main file. Let's fix
that.t
Xavier Claessens
Tristan Partin
Jan Tojnar
Eli Schwartz
Jussi Pakkanen
Önder Görmez
Marco Trevisan (Treviño)
Antoine Jacoutot
Hemmo Nieminen
Remi Thebault
rusty-snake
Dylan Baker